Postgres中禁用Partition Pruning的适用场景是什么？为何设置可开关选项？

一、需要禁用分区裁剪的实际场景 #

实际使用中确实存在少数场景，关闭分区裁剪反而收益更高，常见的有以下几类：

• 分区裁剪规划耗时远高于实际执行耗时的场景：如果你的分区表有几十上百个分区，同时查询过滤条件用到了嵌套自定义函数、复杂多逻辑组合表达式来匹配分区键，规划器计算可裁剪分区的时间会大幅增加，甚至远超过全分区扫描的执行耗时，此时关闭功能反而整体查询速度更快。
• 规避已知裁剪逻辑bug的临时方案：部分旧版本Postgres对特殊分区场景（比如带NULL值的列表分区、多层级嵌套分区）的裁剪逻辑存在缺陷，会错误裁剪符合条件的分区导致查询结果不准确，此时临时关闭分区裁剪可以快速规避问题，等后续升级版本或修复业务逻辑后再开启即可。
• 性能测试与问题排查场景：当你需要做基准性能测试对比、或是排查慢查询根因时，关闭该开关可以快速确认性能问题是否和分区裁剪逻辑有关，方便定位问题。

二、Postgres将该功能设为可配置选项的原因 #

这是PostgreSQL优化器相关功能的常规设计思路，核心出发点有两个：

首先是给用户提供兜底容错能力：任何优化逻辑都无法覆盖100%的业务场景，极端场景下优化动作反而会带来负收益甚至结果异常，可调整的开关可以让用户在遇到问题时快速止损，不需要等待官方版本迭代修复。
其次是方便调试和问题排查：不管是业务侧排查慢查询问题，还是社区开发者定位优化器缺陷，可独立开关的优化项都能快速排除该逻辑的影响，大幅提升问题定位效率。

如果需要临时关闭分区裁剪，对应执行语句如下：

set enable_partition_pruning = off;

可以根据实际需求调整为会话级、事务级或是全局生效。

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