PostgreSQL教程-数据定义-分区剪枝

5.11.4. 分区剪枝

分区剪枝是一种提升声明式分区表性能的查询优化技术。例如：

SET enable_partition_pruning = on; -? the default

SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';

如果没有分区剪枝，上面的查询将会扫描measurement表的每一个分区。如果启用了分区剪枝，规划器将会检查每个分区的定义并且检验该分区是否因为不包含符合查询WHERE子句的行而无需扫描。当规划器可以证实这一点时，它会把分区从查询计划中排除(剪枝)。

通过使用EXPLAIN命令和enable_partition_pruning配置参数，可以展示剪枝掉分区的计划与没有剪枝的计划之间的差别。对这种类型的表设置，一种典型的未优化计划是：

SET enable_partition_pruning = off;

EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';

QUERY PLAN

-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-

Aggregate (cost=188.76..188.77 rows=1 width=8)

-> Append (cost=0.00..181.05 rows=3085 width=0)

-> Seq Scan on measurement_y2006m02 (cost=0.00..33.12 rows=617 width=0)

Filter: (logdate >= '2008-01-01'::date)

-> Seq Scan on measurement_y2006m03 (cost=0.00..33.12 rows=617 width=0)

Filter: (logdate >= '2008-01-01'::date)

...

-> Seq Scan on measurement_y2007m11 (cost=0.00..33.12 rows=617 width=0)

Filter: (logdate >= '2008-01-01'::date)

-> Seq Scan on measurement_y2007m12 (cost=0.00..33.12 rows=617 width=0)

Filter: (logdate >= '2008-01-01'::date)

-> Seq Scan on measurement_y2008m01 (cost=0.00..33.12 rows=617 width=0)

Filter: (logdate >= '2008-01-01'::date)

某些或者全部的分区可能会使用索引扫描取代全表顺序扫描，但是这里的重点是根本不需要扫描较老的分区来回答这个查询。当我们启用分区剪枝时，我们会得到一个便宜很多的计划，而它能给出相同的答案：

SET enable_partition_pruning = on;

EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';

QUERY PLAN

-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-

Aggregate (cost=37.75..37.76 rows=1 width=8)

-> Seq Scan on measurement_y2008m01 (cost=0.00..33.12 rows=617 width=0)

Filter: (logdate >= '2008-01-01'::date)

注意，分区剪枝仅由分区键隐式定义的约束所驱动，而不是由索引的存在驱动。因此，没有必要在键列上定义索引。是否需要为一个给定分区创建索引取决于预期的查询扫描该分区时会扫描大部分还是小部分。后一种情况下索引的帮助会比前者大。

不仅在给定查询的规划期间可以执行分区剪枝，在其执行期间也能执行分区剪枝。 这非常有用，因为如果子句中包含查询规划时值未知的表达式时，这可以剪枝掉更多的分区; 例如在PREPARE语句中定义的参数会使用从子查询拿到的值，或者嵌套循环连接内侧关系上的参数化值。 执行期间的分区剪枝可能在下列任何时刻执行：

在查询计划的初始化期间。对于执行的初始化阶段就已知值的参数，可以在这里执行分区剪枝。这个阶段中被剪枝掉的分区将不会显示在查询的EXPLAIN或EXPLAIN ANALYZE结果中。通过观察EXPLAIN输出的“Subplans Removed”属性，可以确定被剪枝掉的分区数。

在查询计划的实际执行期间。这里可以使用只有在实际查询执行时才能知道的值执行分区剪枝。这包括来自子查询的值以及来自执行时参数的值(例如来自于参数化嵌套循环连接的参数)。由于在查询执行期间这些参数的值可能会改变多次，所以只要分区剪枝使用到的执行参数发生改变，就会执行一次分区剪枝。要判断分区是否在这个阶段被剪枝，需要仔细地观察EXPLAIN ANALYZE输出中的loops属性。 对应于不同分区的子计划可以具有不同的值，这取决于在执行期间每个分区被修剪的次数。 如果每次都被剪枝，有些分区可能会显示为(never executed)。

可以使用enable_partition_pruning设置禁用分区剪枝。

注意

执行时间分区裁剪当前只针对Append和MergeAppend节点类型。 它还没有为ModifyTable节点类型实现，但有可能会在将来发布的 PostgreSQL中更改。