pgrust 逆向设计：新引擎比 ClickHouse 快 3 倍

从下往上优化的天花板：你可能离极限 20%，也可能差 100 倍

看到 pgrust v0.4-beta 发布消息时，我第一反应不是"又一个快引擎"，而是被 ClickBench 这个基准的名字扎了一下。ClickBench 是 ClickHouse 自己设计用来展示自家性能的，结果被一个叫 Gravity 的新引擎最高甩开 3 倍 来源：HH。这就像在对手的主场把对手打趴下，冲击力比普通跑分大得多。

写这个引擎的作者是个明白人。他直接戳穿了常规优化路径的毛病：跑基准、看火焰图、找热点，然后提速 15% 或 20%，这种做法是自下而上的，你永远不知道天花板在哪里。他反问了一句很有分量的话：你可能离硬件能跑出的最快代码只差 20%，也可能还差 100 倍 来源：HH。

于是他把问题翻转过来，不再从现有代码往上挤，而是从硬件和文件格式的物理速度极限反向设计，从极限往回想。作者把这套方法论称作"programming at light speed"，以光速编程 来源：HH。我见过太多"优化半年提升 15%"的汇报，这种翻转思路确实提神醒脑。

Gravity 引擎的技术细节：5 微秒 JIT 与完整 Postgres 方言

Gravity 不是凭空冒出来的。pgrust 之前的版本已经用批处理、算子融合和 SIMD 把分析查询做到比 Postgres 快数百倍 来源：HH。前代的核心是一个 copy-and-patch JIT 编译器，能在 5 微秒内编译 stencil 模板 来源：HH。这些积累都成了 Gravity 的底子。

但作者很清楚 copy-and-patch 的局限：把预编译模板粘在一起只能到这一步，因为没有真正的中间表示（IR），也没有跨循环的寄存器分配，跟 rustc 或 Clang 这样的优化编译器比还是差一截性能 来源：HH。这个判断很实在，JIT 和 AOT 编译器在寄存器分配上的差距，懂编译原理的人一眼就能看出来。

所以 v0.4 的目标定得很高：构建一个能为任意 SQL 查询生成最优机器码的查询编译器，这就是 Gravity 的由来 来源：HH。更难得的是，Gravity 在保持 3 倍速度优势的同时，还支持完整的 Postgres SQL 方言和类型系统 来源：HH。速度上去了，兼容性没丢，这在数据库引擎里算是两难全的活儿。

多源数据交叉验证：ClickHouse 官方基准 vs Postgres 历史性能 vs 优化编译器

三组数据摆在面前，我得承认它们指向同一个结论。第一组是 ClickHouse 自研的 ClickBench 基准，Gravity 比 ClickHouse 快 3 倍 来源：HH 来源：CKB。第二组是历史性能，pgrust 前代 SIMD/算子融合版本比 Postgres 快数百倍 来源：HH 来源：PG，说明 Postgres 分析查询还有巨大空间。

第三组来自编译器工具链。作者承认 copy-and-patch 因缺少 IR 和寄存器分配，不如 rustc/Clang 优化彻底 来源：HH。三个维度各自独立，但都指向同一件事：Gravity 不是局部调优，是从物理极限出发的重新设计。

有个细节让我在意。作者提到让 Claude 参与寻找"光速"的工作，让 AI 写针对分析查询语料的手调 Rust 程序，绕过整个 SQL 执行器直接跑多线程 SIMD 循环。那些手写程序比 ClickHouse 快约 4 倍，作者再从中提炼优化融入 Gravity 来源：HH。原文在具体细节处被截断，我不确定 Claude 在这里到底参与了多少，但 AI 辅助编译器优化这个方向本身就值得盯着看。

如果 Gravity 真能在 ClickHouse 自家设计的基准上快 3 倍，同时保持完整 Postgres 方言，那这个 3 倍可能只是起点。毕竟作者连"光速"在哪都开始算了。

原文：

Pgrust: Gravity Query Engine · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月30日