一条查询从 32 秒压到 37 毫秒

本次更新的最大看点是一条被称为「奖杯查询」的相关子查询（TPC-H 的 Q17）。这条查询要按零件计算平均的 l_quantity，在规模因子 1 的数据集下，旧方案需要针对 600 万行逐一在本地求值，耗时约 32.7 秒；改为完全下推后只需 37 毫秒，差距达到三个数量级，约为 880 倍。

更有意思的是，原生 PostgreSQL 跑同一条查询约需 2.1 秒，而完全下推后的 pg_clickhouse 反而更快。其余几条的提升同样明显：Q2 从 3446 毫秒降到 24 毫秒，Q22 从 1415 毫秒降到 45 毫秒。

子查询是怎么被下推的

新版本的相关子查询路径会把子查询翻译成 ClickHouse 一侧的半连接或反连接，要求服务端 ClickHouse 版本在 25.8 及以上。规划器不再把子查询留作「逐行执行的 SubPlan」，而是直接折叠成连接，从而把计算交给 ClickHouse 完成。

这一能力并非凭空而来：早在 2025 年 12 月，pg_clickhouse 就教会规划器把整条相关 EXISTS 子查询作为单次 LEFT SEMI JOIN 下推，而不是「外层每行一次 ClickHouse 往返」的嵌套循环，当时一举把完全下推查询从 3 条提升到 12 条。

驱动重写与更多下推覆盖

v0.10 用 ClickHouse 的纯 C 客户端库重写了二进制驱动，大结果改为分块流式传输，并新增压缩与 TLS 控制；并发的外部扫描各自使用独立连接，修掉了此前驱动里的几个并发缺陷。

与此同时，能够被下推的函数与聚合数量翻了一倍以上，覆盖了统计聚合、有序集聚合、分区级聚合，以及更多日期运算与字符串函数。

仍是 ClickHouse 的 Postgres 策略一环

pg_clickhouse 于 2025 年 12 月推出，是 ClickHouse 面向 PostgreSQL 用户策略的一部分：在不迁移数据库的前提下，保留 PostgreSQL 这一应用层接口，把繁重的分析执行交给 ClickHouse。其托管的 PostgreSQL 服务于 2026 年 5 月进入公测。

商业化层面，ClickHouse 在 2026 年 1 月完成 4 亿美元 D 轮融资，客户数已超过 4000 家，年化收入约 2.5 亿美元。

目前仍有 6 条 TPC-H 查询（Q13、Q15、Q16、Q18、Q20、Q21）尚未完全下推，这将是下一批子查询下推工作的重点。

来源：ClickHouse 官方博客（经 Hacker News 转载）

PostgreSQL 诞生于磁盘 I/O 是主要瓶颈的年代，而如今很多数据集能直接塞进内存，分析负载的瓶颈早变成了 CPU 和内存带宽。pgrust 的查询引擎单独就贡献了约 10 倍的提速。作者用「求前 5 亿个数的和」这个简单查询来量化差距：同样的活，原生 Postgres 在关掉并行后跑了约 20 秒，而一段朴素的 Rust 循环只要 358 毫秒，快了约 55 倍。

差距的根源在 PostgreSQL 使用的「火山模型」（Volcano model）执行器。它要求每个计划节点都实现一个 next() 方法、一次只返回一行。作者照着这个模型写了个迷你版，耗时 1.3 秒——比原生 Postgres 快，但仍远慢于裸循环，因为每行都调一次函数的开销实在太大。

第一招是批处理。把 next() 改成一次返回 1024 行，绝大多数函数调用开销被抹掉，耗时从 1.3 秒降到约 480 毫秒（2.7 倍）。关键是批处理缓冲区分配在栈上，运行时不再频繁申请内存。

第二招是算子融合。既然顺序扫描和求和总是一前一后出现，就把两个节点合并成一个，省掉中间拷贝，直接回到 358 毫秒（3.6 倍）的裸循环水平。作者坦言这算「作弊」，因为写死了特定查询，但 pgrust 真正的通用解法是 JIT 编译——为每条查询现场生成最优代码，从而对任意查询都能做算子融合。

第三招是 SIMD。在 aarch64 架构上用单指令多数据指令一次处理多行，耗时进一步压到 135 毫秒（9.6 倍），比裸循环还快近 3 倍。代价是浮点加法不满足结合律，求和顺序改变会带来微小误差——这也是编译器默认不敢擅自上 SIMD 的原因。

整套基准跑在 AWS c8g.4xlarge（Graviton4、16 vCPU）上，使用 PostgreSQL 18.4、关闭并行、数据预热进共享缓冲、取 5 次运行的中位数。作者总结，正是批处理、算子融合、SIMD 这些底层优化，让 pgrust 的分析查询达到数百倍于 Postgres 的速度。

来源：malisper.me