Gravity：比ClickHouse快3倍的查询引擎
Programming at Light Speed: Building the Gravity Query Engine
随着pgrust v0.4-beta的发布，我们推出了全新的Gravity查询引擎。在ClickHouse自己设计的ClickBench基准测试中，Gravity的查询速度最高可达ClickHouse的3倍，同时完全支持Postgres SQL方言和类型系统。我们摒弃了传统的自底向上优化模式，转而采用“光速编程”理念：先让Claude编写直接操作列式存储的手写Rust程序，以此确立硬件物理极限，再反向构建编译器。Gravity通过多阶段编译管道，将SQL查询转化为Lisp IR，最终生成接近手写代码性能的机器码。这种从物理极限倒推的设计思路，让数据库性能真正逼近理论天花板。
当我们开始构建Gravity时，我们将这个问题反过来问：数据库实际上能有多快？
- landhar
> 通常，当工程师试图让软件更快时，他们采用的是自下而上的方法。他们运行基准测试，查看火焰图（flamegraph），找到热点，然后想办法让代码提速 15% 或 20%。自下而上这种方法的问题在于，你不知道上限在哪里。你可能离硬件能运行的最快代码只差 20%，也可能差了 100 倍。
> 当我们开始构建 Gravity 时，我们把这个思路反过来了。我们问自己：数据库实际上能有多快？我们不想只是逐步加速现有的查询引擎，而是想从硬件和文件格式的物理速度极限出发，反向推导。我喜欢把这称为“以光速编程”。
文中描述的所谓“常规”代码优化方法，其实更像是“天真”的方法。任何严肃的性能优化工作，都会先定义硬件允许的上限，并据此进行基准测试。而且在 LLM 出现之前，情况就已经是这样了。
例如参见：https://www.marginalia.nu/log/a_106_native_calls/
抱歉有点吹毛求疵，但我觉得让其他读者了解这种方法论并非新颖之处是有帮助的。他们用 Claude 生成那些优化后的基准测试已经足够有趣了，所以我觉得没必要在文章中额外强调这部分。
- cube2222
在 clickbench 最近那些有些令人沮丧的事情上了新闻之后，我必须说这篇博客非常酷。
听起来你们找到了一种绝佳的架构方式，用 Claude 来解决这个问题（对于那些没点进文章的人——为每个查询编写由人类/ Claude 优化的 Rust 代码，检查其汇编，并尝试让他们的优化器生成与之接近的汇编），而且文章本身也写得非常有趣、易读！
赞，期待看到更多这样的博客文章。
- agumonkey
pgrust 那帮人历史上是 Lisp 程序员吗？