一条查询从 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 转载）