Alexander Ioffe：同一个查询跑两次，Postgres 却给出了自相矛盾的答案
内容提要
Postgres 可能因代价估算的微小波动为同一查询选择截然不同的执行计划，导致堆块访问从 73 暴增至 3449。作者用 ExoBench 在合成 FEC 数据上复现了这一“计划抛硬币”现象，发现两索引方案不稳定。最终通过创建单个多列 GIN 索引（结合 btree_gin 与 pg_trgm）将交集下推到索引内部，消除规划器决策，使查询从 193.8 毫秒降至 0.76 毫秒。
延伸解读
计划不稳定的根源：代价估算的微小波动
Postgres 的代价模型基于统计信息估算行数，但估算值可能剧烈波动。文中同一查询两次运行，trigram 索引的估算行数从 141 到 14,215，而实际约 3,500。这种波动导致两个计划的代价仅差 1.5%，规划器便可能选择截然不同的执行路径，堆块访问从 73 暴增至 3449。这不是 bug，而是基于代价的优化器在统计信息不准确时的固有行为。
索引策略的陷阱：单独使用 trigram GIN 的局限
单独在 employer 列上建 trigram GIN 索引，虽然能快速找到所有匹配 '%MICROSOFT%' 的行，但会忽略州和日期等过滤条件。文中该索引返回了全国范围内约 1,080 个堆块，再过滤出少量行，代价随匹配总数增长。若查询条件包含高选择性列，应让索引同时处理多个条件，而非依赖堆过滤。
稳定方案：多列 GIN 索引将交集下推
作者最终采用一个多列 GIN 索引，结合 btree_gin 和 pg_trgm，将州、日期和雇主模糊匹配全部下推到索引内部。这样规划器无需在多个索引间选择，消除了决策波动。在 1M 行 JSONB 表上，查询从 193.8 毫秒降至 0.76 毫秒。对于多条件查询，复合索引往往比多个单列索引更稳定高效。
对生产环境的启示：关注统计信息与计划稳定性
生产环境中，ANALYZE 会定期重新采样，估算值可能变化，导致计划翻转。若查询性能对计划敏感，应考虑使用多列索引、表达式索引配合 CREATE STATISTICS，或固定计划。文中还指出，JSONB 并非性能问题的根源，控制实验在普通列上同样出现计划翻转，说明问题在于规划器对多条件交集的处理方式。
Q&A
为什么同一个查询在Postgres中会得到不同的执行计划？
因为Postgres的代价估算存在微小波动，导致规划器为同一查询选择截然不同的执行计划。例如，两个候选计划的代价仅相差19个代价单位（约1.5%），但一个计划访问73个堆块，另一个访问3449个堆块。这种波动源于ANALYZE采样时对选择性的估计不稳定，估计行数可能在140到14215之间变化，而真实行数约为3500。
如何解决Postgres因代价估算波动导致的执行计划不稳定问题？
创建一个结合btree_gin和pg_trgm的多列GIN索引，将多个条件的交集下推到索引内部，从而消除规划器的决策。在原始100万行的JSONB表上，该索引将查询时间从193.8毫秒降至0.76毫秒。
在JSONB列上使用表达式索引有什么风险？
在JSONB列上使用表达式索引可能导致规划器错误估计行数，因为Postgres没有跨JSONB表达式的相关性统计信息。例如，一个(state, date)表达式btree索引被规划器选中，估计行数为1，但实际返回4154行，其中4145行被过滤掉，导致性能比全表扫描更差。建议搭配CREATE STATISTICS来改善估计。
单独使用trigram GIN索引有什么局限性？
单独使用trigram GIN索引时，其代价与全国范围内匹配的行数成正比，而不考虑其他过滤条件（如州和日期）的筛选性。例如，在100万行数据上，它返回1082行，但实际只需要5行，导致访问1080个堆块，性能不佳。
Postgres的代价单位（cost units）是什么？为什么微小的代价差异会导致巨大的性能差异？
代价单位是查询规划器使用的纯数学测量单位，并不直接对应现实中的时间或资源。规划器用它们来比较未实际运行的执行计划。微小的代价差异（如19单位，约1.5%）可能源于对行数估计的波动，而估计行数可能波动100倍（如从140到14215），导致规划器选择截然不同的计划，从而造成堆块访问从73到3449的巨大差异。
如何复现Postgres执行计划不稳定的现象？
可以使用ExoBench工具，它能够根据指定的模式和數據形状生成合成数据，并在不同规模下运行EXPLAIN (ANALYZE, BUFFERS)。每次基准测试都会从相同的生成器构建全新的数据库，从而独立抽取相同分布的数据，这有助于观察到规划器在不同运行中选择不同计划的现象。
