PostgreSQL为何选择低效执行计划？CLUSTER索引致BRIN索引失效

核心逻辑：聚簇索引改变了优化器对全表扫描的成本估算 #

当表通过CLUSTER命令关联了(bizdate, datepayment)的BTREE索引后，PostgreSQL会在系统元数据中将该索引标记为表的聚簇索引（pg_class.relcluster字段指向该索引的OID）。优化器会对这类聚簇表采用特殊的成本估算逻辑：

• 由于表数据已按聚簇索引的键物理排序，再结合pg_stats中bizdate字段相关性为1的统计，优化器会判定符合bizdate>='2022-12-03'条件的数据在磁盘上是连续存储的块。它会大幅低估全表扫描的I/O成本——认为只需扫描连续的部分数据块，而非整个14GB的表。
• 你的查询中，聚簇BTREE索引虽不包含bo字段，无法直接过滤该条件，但优化器估算后认为：先通过连续块扫描获取bizdate符合条件的数据，再在内存中过滤datepayment和bo的成本，比走BRIN索引的成本更低，因此选择了并行全表扫描。

无聚簇索引的cf2为何选择BRIN？ #

cf2的数据物理顺序与cf1一致，但没有被标记为聚簇表（无关联的聚簇索引）。优化器不会默认数据是连续存储的，因此会正常评估各执行计划的成本：

• BRIN索引针对bizdate的范围查询成本极低（只需扫描少量索引块即可定位符合条件的数据块），结合后续过滤条件后整体成本远低于全表扫描，因此优化器选择BRIN索引扫描计划。

删除聚簇索引后cf1行为恢复的原因 #

当删除cf1的聚簇BTREE索引后，系统元数据中不再标记该表为聚簇表，优化器失去了“数据连续存储”的特殊假设，会以普通表的逻辑重新估算成本：

• 此时全表扫描的成本会被正常计算（需扫描整个14GB表），而BRIN索引的低成本优势凸显，优化器自然会选择更高效的BRIN索引扫描计划。

内容的提问来源于stack exchange，提问作者dddmmmxxx