把 Postgres 改快 300 倍：pgrust 赢在批处理和 SIMD，但赢的是哪类查询
作者：林岚｜OC 开发者生态编辑
作者：林岚｜OC 开发者生态编辑
据 pgrust 开发者 Michael Malis 的 技术说明，实验性 PostgreSQL Rust 重写项目在 0.2 版更换查询执行引擎后，部分分析任务比上一版本快约 10 倍，在团队选择的 OLTP 基准中约为 PostgreSQL 的 30 倍，在 ClickBench 中最高达到约 300 倍。一个简单求和测试从约 20 秒降到 135 毫秒。
一句话结论：这些数字证明批处理、算子融合和 SIMD 能消除 PostgreSQL 经典执行器在分析查询里的大量逐行开销，但不能证明 pgrust 已经把完整 PostgreSQL 变快 300 倍，更不能直接推导它适合生产替换。
传统 Volcano 风格执行器常让上层算子一次向下请求一行。接口清晰、组合灵活，却会在扫描海量数据时产生大量函数调用、分支和中间对象。pgrust 的新执行器一次处理一批数据，并把过滤、投影和聚合等步骤尽可能融合，让编译器更容易利用缓存和 SIMD 指令。
这正好击中 ClickBench 的特点。该基准以大规模分析聚合为主，数据扫描和数值计算占据主要时间，向量化执行器可以充分发挥优势。简单 SUM 从 20 秒降到 135 毫秒，也主要展示执行循环被压缩后的吞吐提升。
但数据库性能远不只执行器。高并发事务、WAL 持久化、锁竞争、查询规划、索引选择、磁盘故障恢复、复制和扩展兼容都可能决定生产表现。pgrust 官方将项目定义为实验性 PostgreSQL 重写，虽然已通过 PostgreSQL 默认回归测试套件的 46066 个查询，路线图仍包含多线程服务器内部结构和连接池等工作。
“30 倍 OLTP”也需要看测试配置。内存数据、单用户、预热状态、事务耐久性设置和硬件都会改变结果。兼容测试通过说明许多 SQL 行为一致，不等于边缘语义、扩展 ABI 和长时间运行可靠性已经等同 PostgreSQL。
项目真正有价值的地方，是把一个长期存在的架构取舍做成可运行实验：保留 PostgreSQL 行为和生态语义，同时用 Rust 和现代执行技术重做内部。即使 pgrust 最终没有成为生产数据库，它也可能验证哪些设计值得进入 PostgreSQL、扩展或新的兼容实现。
关键事实
- pgrust 0.2 的查询引擎采用批处理、算子融合和 SIMD 优化
- 项目报告部分 OLTP 基准约快 30 倍，ClickBench 最高约快 300 倍
- 简单求和测试由约 20 秒降至 135 毫秒
- 项目仍属实验性，基准优势不能泛化到完整生产工作负载
OC 判断
pgrust 最值得关注的不是“Rust 又赢了”，而是兼容 PostgreSQL 语义时，执行器还剩多少现代化空间。性能数字应按查询类型阅读：分析扫描的突破是真实信号，生产替代的结论则远未成立。
为什么重要
- 对数据库开发者：批处理边界、数据布局和算子融合往往比单个函数微优化更重要。
- 对使用者：评估数据库时要复现自己的并发、持久化、索引和数据规模，不能只看 ClickBench。
- 对 PostgreSQL 生态：兼容重写可以成为架构实验场，并为上游优化提供可测证据。
评论
围绕这篇文章补充信息、提出问题或分享观察。