2024 年 4 月 12 日
作为一名查询优化研究人员，我一生中的最后 10 年都在研究、学习和构建最复杂的开源查询优化器， PostgreSQL。 我最近想知道自从我开始研究数据库以来的十年里 PostgreSQL 进步了多少。 虽然变更日志和意见文章很多，但我找不到任何强有力的实证比较，因此我决定运行 加入订单基准 （工作） 在 PostgreSQL 8 到 16 上。我记录了每个数据库版本的 90% 查询延迟。
我构建了每个版本 在带有 Arch Linux 的 Docker 容器中使用 GCC 13.2 的 PostgreSQL。 因为我想测量查询优化器的质量，而不是索引/IO 性能，所以我设置 shared_buffers 到 8GB（足够容纳整个数据库）。 我也设置了 work_mem 所有版本均为 8MB。 每个查询执行一次以预热缓存，然后记录 5 次额外运行的中值延迟。
全面的， PostgreSQL 的尾部性能大幅提升，尽管版本 13 到 16 大部分都是稳定的。 比较版本 8 和版本 16， PostgreSQL 的优化器在过去 10 年中将尾部延迟降低了近一半！
我们还可以调查整个查询分布（注意对数比例）：
我们可以使用回归分析来（1）确认延迟的下降趋势是显着的，（2）量化每个版本的 PostgreSQL 带来了多少改进。 如果我们根据查询延迟回归 PostgreSQL 主要版本号，我们会发现 PostgreSQL 的每个新主要版本平均带来 15% 性能提升 在连接顺序基准上（）。 然而，线性模型可以说是衡量变化的一个糟糕方法（）。
当然，并非所有这些改进都归功于查询优化器。 执行引擎的改进——从并行工作程序到即时（JIT）编译——也发挥了作用。 研究一下 JOB 中的每个查询计划在这一年中如何变化会很有趣……也许下次吧！
除了量化改进之外：
- 升级你的数据库！ 从 PostgreSQL 8 升级到 16 有可能大幅改善工作负载的尾部延迟。
- 研究人员应该注意到 PostgreSQL 是一个不断变化的目标。 随着时间的推移，学习的查询优化研究与不同版本的 PostgreSQL 进行了比较（例如，Neo 和 Bao 与版本 11 进行比较，而较新的工作与版本 14、15 或 16 进行比较。）因此，仅仅因为较旧的技术在 PostgreSQL 上改进了 30% ，而较新的技术仅比 PostgreSQL 提高了 25%，较新的技术可能是与更强大的 PostgreSQL 进行比较。
您也可以自己查看原始数据。
