让 Postgres 分析快 300 倍：批处理与 SIMD
Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD
上周我们发布了 pgrust 0.2 版本，在 Clickbench 基准测试中，其分析性能比 Postgres 快了 300 倍，甚至超越了 Clickhouse。Postgres 诞生于磁盘 I/O 是瓶颈的时代，而现代硬件让 CPU 和内存速度成为关键。我们深入剖析了查询引擎，从原始的 Volcano 模型出发，通过引入批处理（batching）消除逐行处理的开销，利用算子融合（operator fusion）减少中间数据拷贝，并借助 SIMD 指令集实现并行计算。仅这三项优化，就让我们构建的微型引擎性能提升了 10 倍。这篇文章将带你一步步拆解这些底层优化，看看如何榨干 CPU 性能，让数据库查询快如闪电。
Postgres 诞生于一个不同的时代，当时数据库性能的主要瓶颈是磁盘 I/O，但如今这一情况已不复存在。
- malisper
作者在此。如果大家对这篇文章或 pgrust 有任何疑问，请随时提出。
让我试着回答我认为最常见的问题：我该如何信任 pgrust？目前我们的首要任务是正确性。在过去的两周里，我结合了形式化验证和差异模糊测试（differential fuzz testing）。我们已证明超过 1000 个面向用户的功能在 pgrust 和 postgres 中具有完全相同的逻辑（如果你好奇，可以查看 proofs 目录）。对于那些难以进行形式化验证的情况，我们取一个功能的 C 实现和一个功能的 Rust 实现，将数百万个输入分别传入两者，并确认它们每次都能给出相同的结果。
目前我们仅覆盖了约 15% 的功能范围，但在此过程中，我们发现了 pgrust 中约 100 个 bug，以及 Postgres 本身约 20 个 bug。我们发现的最喜欢的 Postgres bug 是这一个 [0]。Postgres 有一个四叉树（quadtree）实现。由于浮点数舍入问题，一个点可能既不在四叉树中心点的上方，也不在下方，甚至不在同一水平线上。
我们还与 Antithesis [1] 合作进行 Jepsen 风格的故障测试，并与 Aretta [2] 合作进行更严格的形式化验证。
如果你想支持这个项目，最简单的方法是在 GitHub 上给我们点个星 [3]。
- sgt
很酷的项目，但……现实是，人们通常不会选择 pgrust 而不是 Postgres，哪怕是在 5 到 10 年后。问题不在于它在技术上是否更优越、速度更快，而在于它并非由受信任的 Postgres 团队构建。信任不仅仅关乎开发速度或性能，还关乎关键技术的长期稳定性和延续性。
- AsyncBanana
你根本不知道我等自适应规划（adaptive planning）等了多久。Postgres 核心团队最让我恼火的一点是，尽管自适应规划如今已成为一项成熟的技术，并在多个生产级数据库中得以实现，他们却始终不愿实施任何形式的自适应规划。我希望至少这篇文章能证明，该模式在学术或小众领域之外也是可行的。
- rastignack
我认为除了让它更快之外，如果能把它做得更“精简”也会很有用，例如在比 PG 配置更低的硬件上运行得更好。
- kopirgan
感谢作者选择了一款尊重用户自由的许可证，这本身就是一个很棒的技术项目。