把 Postgres 提速 300 倍：一个开发者靠批处理和 SIMD 把分析查询打到了新极限

海外独立开发者社区最近流传一份特别硬核的技术实战笔记，作者叫 Malcolm，一个长期做后端性能优化的开发者。他在博客里详细拆解了自己怎么把 Postgres 在分析查询场景下的速度从平均几十秒压到了零点几秒，整体提速接近 300 倍，而且没有引入任何额外的重型数据仓库。这份笔记在 Hacker News 上一度冲到技术板块首页，被讨论的核心不是「Postgres 有多强」，而是「这种针对查询引擎本身的细粒度优化，普通人到底能学到多少」。

先把作者公开的关键数据摆出来。Malcolm 给出的基准测试场景是 1 亿行的事实表加上几张千万级的维度表，跑一组典型的星型连接加分组聚合查询。原始 Postgres 在没有做任何调整的情况下，这组查询平均耗时 38 秒，调优后压到了 0.13 秒。提速不是单点突破，而是三件事叠加的结果：第一是查询层面的批处理，把原本一条一条发的子查询合并成批量请求；第二是操作符融合，把多个简单的算子合并成一个向量化算子，减少每行的指令数；第三是 SIMD 指令，把 CPU 的向量寄存器真正用起来，让一周期处理多行数据。这三件事单独做每件都能提速 5 到 10 倍，叠加在一起出现了 300 倍这种接近乘法效应的结果。

值得专门讲一下的是 SIMD 这件事。Postgres 默认的执行器是逐行迭代的，每处理一行都要走一遍完整的算子调用栈，这种模式在 CPU 层面是非常浪费的。Malcolm 的做法是把常见的比较、算术、字符串处理这些算子重写成 SIMD 版本，一周期能同时处理 8 到 16 行。这种改造对单条查询的延迟影响极大，但对 Postgres 这种通用数据库来说一直没有官方跟进，因为改动会侵入执行器的核心代码。Malcolm 把这部分改写做成了独立的项目 fork，普通开发者可以直接拿来在自家数据量上复现。

批处理这块的优化路径更有普适性。分析查询慢的常见原因是应用层发起的请求太多，每发一条都有一次网络往返和一次 SQL 解析开销。把多条子查询合并成一条大查询，或者用 CTE（公共表表达式）一次性把中间结果算出来反复使用，能把网络和解析的开销砍掉一两个数量级。这个改动的工程量远小于 SIMD 优化，但对绝大多数业务系统来说已经能拿到 10 倍以上的提速，是性价比最高的优化起点。

对所有正在用 Postgres 做后端存储、正在面对报表查询慢、正在考虑要不要上 ClickHouse 或者 Snowflake 的开发者来说，Malcolm 的实战笔记至少提示了三件事。第一，Postgres 本身的能力远没有被普通团队用满，绝大多数「慢」其实是配置和使用方式的问题，不是数据库的极限。第二，向量化和 SIMD 是分析型数据库的核心战场，传统行式数据库想要在这个方向追赶，需要在执行器层面做深度重构，这条路对独立开发者来说门槛很高，但对应用层调优来说反而是机会。第三，不要轻易引入新组件。重型数据仓库的运维成本和迁移成本远比想象的高，先把现有 Postgres 的极限榨出来，能省下大量时间和预算。

短期窗口期内值得关注的是 Malcolm 的项目是否会被上游 Postgres 社区采纳，以及类似的向量化执行器改造会不会在 17 或者 18 版本里以插件形式出现。如果你是后端工程师、数据工程师、SaaS 产品的技术负责人，强烈建议把这份实战笔记完整读一遍，里面的具体改造思路可以直接复用到自家项目上，省下来的可能是几台到几十台服务器的成本。

（来源：hackernoon 2026 年 8 月稿件《Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD》）

创业找资源，上乌鸦部落。