ClickHouse 的 pg_clickhouse v0.10 将 TPC-H Q17 的运行时间缩短了 884 倍

Why it matters

ClickHouse is using pg_clickhouse to make its analytical engine adoptable without a wholesale PostgreSQL migration. The 884x Q17 result shows the payoff when pushdown works, while the remaining query gaps define the engineering risk.

ClickHouse engineer Josh Ventura released pg_clickhouse v0.10.0 on August 11, pushing more PostgreSQL subqueries into ClickHouse and cutting one vendor-tested TPC-H query from 32.7 seconds to 37 milliseconds.

该发布推进了 ClickHouse 联合创始人兼 CTO Alexey Milovidov 在 2009 年开始构建的架构目标：随着底层数据增长，保持分析查询的交互性。底层的 ClickHouse 系统在 2012 年进入 Yandex.Metrica 的生产环境，并在 2016 年成为开源项目。联合创始人 Aaron Katz 和 Yury Izrailevsky 随后帮助将该数据库发展成独立业务，pg_clickhouse 则将相同的性能赌注扩展到 PostgreSQL，而不是要求开发者放弃他们应用已在使用的接口。

在一篇 宣布 v0.10.0 的工程帖子 中，Ventura 将此次发布的直接目标描述为在包含 22 个查询的 TPC-H 基准上实现完整的查询下推。该项目已从 12 个完全下推的查询进展到 16 个，仍有六个待解决。

结果比“1000 倍更快”这类简化说法要有限得多。ClickHouse 在 TPC-H Q17（一个在尺度因子 1 下的特定相关子查询工作负载）上测得约 884 倍的提升。上述数字为厂商基准测试，并不能证明在安装该扩展后 PostgreSQL 工作负载通常会变得快数百倍。

但它们展示了执行位置为何重要。

Moving the work instead of the rows

pg_clickhouse 是一个开源的 PostgreSQL 扩展和外部数据包装器。它允许 PostgreSQL 会话查询存放在 ClickHouse 中的表，同时尝试将过滤器、连接、聚合和其他受支持的操作发送到 ClickHouse 进行远程执行。

在 v0.10.0 之前，某些相关子查询仍以本地 PostgreSQL 计划存在。pg_clickhouse 可能最终从 ClickHouse 检索行并对每个外层行在本地评估子查询。这样的设计抹消了将分析数据放入列式数据库的优势，因为该扩展在数据库边界间移动了大量结果集，并在 PostgreSQL 内部重复执行工作。

Ventura 的团队更改了规划器和反解析器，使受支持的 PostgreSQL 子查询在远程 SQL 语句中成为 ClickHouse 子查询。Ventura 简单概括了这一变化：“现在，Postgres 中的子查询会成为 ClickHouse 中的子查询。”

Q17 提供了最清晰的例子。该查询通过对 600 万条行项目进行相关子查询，为每个零件计算平均数量。ClickHouse 报告称 pg_clickhouse v0.3 在该操作本地评估时耗时 32,709 毫秒。将完整查询发送到 ClickHouse 后，v0.10 在 37 毫秒内完成。相同公布测试中，原生 PostgreSQL 耗时 2,107 毫秒。

该项目的当前基准表 表明测试在一台配备 M4 Max 处理器和 36 GB 内存的 MacBook Pro 上使用 TPC-H 尺度因子 1 进行。Q2 在 pg_clickhouse v0.3 中从 3,446 毫秒降至 v0.10 的 24 毫秒。Q22 从 1,415 毫秒降至 45 毫秒，尽管 Q22 仍然使用多个远程扫描而不是单个外部扫描。

这些限定条件很重要。TPC-H 是一个受控的决策支持基准，公布的数字仅覆盖一台机器、一种数据规模和选定的查询计划。ClickHouse 尚未公布 pg_clickhouse 的部署数量、生产客户结果或可归因于该扩展的收入。

Query correctness became the harder problem

将 SQL 发送到另一个数据库引擎会产生第二个义务：远程查询必须返回 PostgreSQL 本来会产生的结果。

Ventura 将发布的一部分工作集中在涉及空值的 IN、NOT IN、ANY 和 ALL 表达式上。PostgreSQL 使用三值逻辑，表达式可以求值为 true、false 或 null。ClickHouse 对这些操作的默认行为使用二值逻辑。因此，简单的翻译可能会返回 PostgreSQL 本应过滤掉的行。

0.10 版基于表达式的消费方式以及 pg_clickhouse 是否能证明其操作数不可能为 null 添加了保护措施。该方法降低了表面上成功的查询产生细微不同答案的风险。

新的相关子查询路径需要 ClickHouse 25.8 或更高版本。pg_clickhouse 在规划期间会检查服务器版本，当所连接的 ClickHouse 服务器无法处理翻译后的查询时会回退到本地评估。

六个 TPC-H 查询仍未实现完全下推：Q13、Q15、Q16、Q18、Q20 和 Q21。其中若干被阻塞的原因是 PostgreSQL 将它们的子查询转换为其输入包含额外连接的反连接或半连接。pg_clickhouse 的反解析器尚无法遍历该操作两侧的连接树。ClickHouse 将那部分规划器工作识别为下一项主要步骤。

The extension is becoming part of ClickHouse's Postgres strategy

ClickHouse 在 2025 年 12 月推出 pg_clickhouse，以减少在分析数据从 PostgreSQL 迁移时对应用端的额外工作。前提是通过复制移动数据变得更容易，而重写多年嵌入在仪表盘、对象关系映射器和计划任务中的 SQL 仍然代价高昂。

该扩展此后已成为 Postgres managed by ClickHouse 的一个组成部分，该服务在 2026 年 5 月进入公测。该服务将用于事务的 PostgreSQL、将变更数据捕获到 ClickHouse 的流程以及作为跨两个系统查询层的 pg_clickhouse 结合在一起。其战略价值在于保留 PostgreSQL 作为面向应用的接口，同时让 ClickHouse 承担更重的分析执行。

该策略面向那些已经依赖 PostgreSQL 并会抵制完全数据库迁移的客户。它也给工程团队施加了压力，必须支持 PostgreSQL 查询行为的长尾部分，其中兼容性失败通常比明显错误更难被发现。

ClickHouse 有足够资金继续推进这张清单。今年一月，ClickHouse 完成了由 Dragoneer Investment Group 领投的 4 亿美元 D 轮融资，参与者包括 Bessemer Venture Partners、GIC、Index Ventures、Khosla Ventures、Lightspeed Venture Partners、T. Rowe Price 顾问账户和 WCM Investment Management。ClickHouse 在五月表示其已超过 4000 家客户并达到 2.5 亿美元的年经常性收入运行率。

0.10 版还围绕 ClickHouse 的纯 C 客户端库重建了二进制驱动，按块流式传输大结果集，增加了压缩和 TLS 控制，并为并发的外部扫描提供独立连接。后者的改动解决了驱动中的并发错误。ClickHouse 还扩展了对统计聚合、有序集合聚合、分区聚合、日期操作和字符串函数的下推支持。

基准性能的提升会引起关注，但 pg_clickhouse 更大的考验是兼容性。Milovidov 围绕快速分析执行构建了 ClickHouse。该公司现在押注于能否在开发者已经信任的 PostgreSQL 接口后面销售这台引擎。Ventura 的子查询工作弥补了若干最昂贵的缺口，但在六个基准查询之外，还有一个更大的生产 SQL 世界等待解决。