PostgreSQL分区父表查询执行计划与子表不一致问题咨询

根因分析 #

• 版本固有缺陷：传统继承分区统计信息偏差：你使用的PostgreSQL 9.6版本仅支持基于表继承实现的传统分区，未内置声明式分区能力。父表import_request的统计信息是所有子表的汇总值，当查询过滤条件仅命中单个分区（enterprise_id=133）时，规划器仍会基于父表的全局统计做行数估算，得到的数值远高于单分区真实行数，最终错误选择了低效的连接顺序、连接算法或排序方案。
• 分区裁剪逻辑配置异常：如果constraint_exclusion参数未设置为partition或on，会导致分区裁剪失效，父表查询会扫描全部分区而非仅命中的133对应子表，直接导致性能劣化。
• 过滤条件加剧估算误差：查询中使用的extraction_status / 1000 IN (8,9)属于表达式过滤，若该字段未创建对应表达式索引或统计信息，会进一步放大行数估算的偏差，导致执行计划错误。

解决方案 #

临时适配方案（无需升级版本） #

• 检查参数配置：确认constraint_exclusion参数值为partition，保证分区裁剪逻辑正常生效。
• 优化过滤条件：将extraction_status / 1000 IN (8,9)改写为extraction_status BETWEEN 8000 AND 9999，避免表达式过滤导致的估算误差，同时可更好命中普通索引。
• 优化统计信息：调大default_statistics_target参数值（可从默认100调整至1000），执行ANALYZE import_request;和ANALYZE import_request_133;重新收集全表和目标分区的统计信息，提升规划器估算准确率。
• 业务层路由：若查询时enterprise_id为明确固定值，可在业务层直接路由到对应子表执行查询，绕开父表统计偏差问题。
• 强制执行计划：如果业务场景固定，可安装pg_hint_plan插件，通过hint指定正确的连接顺序、连接算法，强制规划器走最优执行计划。

长期根治方案 #

升级PostgreSQL到10及以上版本，使用官方内置的声明式分区能力。新版本针对分区场景的裁剪逻辑、统计信息估算、执行计划生成都做了大量优化，单分区过滤场景下父表查询可直接复用目标子表的细粒度统计信息，不会出现父表查询性能远低于子表的问题。

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