分区裁剪是PostgreSQL根据查询条件自动排除不相关分区以减少扫描数据量的优化技术，例如查询order_date='2024-03-15'时仅扫描orders_2024分区，通过约束排除机制在计划或运行时实现静态与动态裁剪。
PostgreSQL 的分区裁剪（Partition Pruning）是一种查询优化技术，能够在执行查询时自动排除不相关的分区，从而减少扫描的数据量，提升查询性能。它是在查询计划阶段由优化器完成的，不需要手动干预。
什么是分区裁剪？
当表被划分为多个分区后，如果查询条件中包含了分区键，PostgreSQL 可以根据这些条件判断哪些分区不可能包含目标数据，进而在生成执行计划时跳过这些分区。这个过程就叫分区裁剪。
例如，有一个按时间范围分区的订单表：
CREATE TABLE orders ( id int, order_date date ) PARTITION BY RANGE (order_date);
CREATE TABLE orders_2023 PARTITION OF orders
FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
CREATE TABLE orders_2024 PARTITION OF orders
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
执行如下查询：
SELECT * FROM orders WHERE order_date = '2024-03-15';优化器会分析条件 order_date = '2024-03-15'，发现只有 orders_2024 分区可能包含该数据，于是自动排除 orders_2023，只扫描目标分区。这就是分区裁剪的实际体现。
分区裁剪是如何实现的？
PostgreSQL 在查询重写和执行计划生成阶段通过以下机制实现裁剪：
- 静态裁剪：在查询计划阶段就能确定哪些分区可以排除。比如上面的例子，常量条件可以直接匹配分区边界，优化器无需运行时信息即可裁剪。
- 动态裁剪：在 PostgreSQL 11+ 中引入了对参数化查询和连接条件的支持。如果查询使用了参数或与其他表进行连接，且连接字段是分区键，PostgreSQL 能在运行时根据实际值进一步裁剪分区。
- 约束排除（Constraint Exclusion）：这是实现裁剪的核心机制。每个分区都有一个隐式或显式的 CHECK 约束（如 order_date ≥ '2023-01-01' AND order_date
注意：要启用基于约束的裁剪，需要确保参数 constraint_exclusion 设置为 on 或 partition（推荐设为 partition）。
如何验证分区裁剪是否生效？
使用 EXPLAIN 命令查看执行计划：
EXPLAIN SELECT * FROM orders WHERE order_date = '2024-03-15';
如果裁剪成功，输出中只会显示访问了 orders_2024，而不会出现 orders_2023。
若看到所有分区都被扫描，说明裁剪未生效，常见原因包括：
- 查询条件未包含分区键
- 分区键上使用了函数，如 WHERE EXTRACT(YEAR FROM order_date) = 2024
- 数据类型不匹配导致无法比较（如字符串与日期混用）
- 约束未正确生成或被禁用
提升裁剪效率的最佳实践
- 确保查询中的分区键以原始形式出现在 WHERE 子句中，避免包裹函数
- 合理设计分区策略（范围、列表、哈希），优先选择能最大化裁剪效果的方式
- 定期检查执行计划，确认不必要的分区未被扫描
- 升级到较新的 PostgreSQL 版本（如 12+），以获得更智能的动态裁剪支持
- 避免过度分区，太多小分区会增加元数据开销，反而影响性能
基本上就这些。只要结构清晰、条件明确，PostgreSQL 的分区裁剪机制能自动高效工作，显著提升大表查询速度。
