7). 确保postgresql.conf里的配置参数constraint_exclusion是打开的。没有这个参数，查询不会按照需要进行优化。这里我们需要做的是确保该选项在配置文件中没有被注释掉。

/> pwd

/opt/PostgreSQL/9.1/data

/> cat postgresql.conf | grep "constraint_exclusion"

constraint_exclusion = partition # on, off, or partition

3. 分区和约束排除：

约束排除(Constraint exclusion)是一种查询优化技巧，它改进了用上面方法定义的表分区的性能。比如：

SET constraint_exclusion = on;

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

如果没有约束排除，上面的查询会扫描measurement表中的每一个分区。打开了约束排除之后，规划器将检查每个分区的约束然后再视图证明该分区不需要被扫描，因为它不能包含任何符合WHERE子句条件的数据行。如果规划器可以证明这个，它就把该分区从查询规划里排除出去。

你可以使用EXPLAIN命令显示一个规划在constraint_exclusion打开和关闭情况下的不同。用上面方法设置的表的典型的缺省规划是：

SET constraint_exclusion = off;

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

QUERY PLAN

-----------------------------------------------------------------------------------------------

Aggregate (cost=158.66..158.68 rows=1 width=0)

-> Append (cost=0.00..151.88 rows=2715 width=0)

-> Seq Scan on measurement (cost=0.00..30.38 rows=543 width=0)

Filter: (logdate >= '2006-01-01'::date) www.2cto.com

-> Seq Scan on measurement_yy04mm02 measurement (cost=0.00..30.38 rows=543 width=0)

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

-> Seq Scan on measurement_yy04mm03 measurement (cost=0.00..30.38 rows=543 width=0)

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

...

-> Seq Scan on measurement_yy05mm12 measurement (cost=0.00..30.38 rows=543 width=0)

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

-> Seq Scan on measurement_yy06mm01 measurement (cost=0.00..30.38 rows=543 width=0)

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

从上面的查询计划中可以看出，PostgreSQL扫描了所有分区。下面我们再看一下打开约束排除之后的查询计划：

SET constraint_exclusion = on;

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

QUERY PLAN www.2cto.com

-----------------------------------------------------------------------------------------------

Aggregate (cost=63.47..63.48 rows=1 width=0)

-> Append (cost=0.00..60.75 rows=1086 width=0)

-> Seq Scan on measurement (cost=0.00..30.38 rows=543 width=0)

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

-> Seq Scan on measurement_yy06mm01 measurement (cost=0.00..30.38 rows=543 width=0)

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

请注意，约束排除只由CHECK约束驱动，而不会由索引驱动。

目前版本的PostgreSQL中该配置的缺省值是partition，该值是介于on和off之间的一种行为方式，即规划器只会将约束排除应用于基于分区表的查询，而on设置则会为所有查询都进行约束排除，那么对于普通数据表而言，也将不得不承担由该机制而产生的额外开销。

约束排除在使用时有以下几点注意事项：

1). 约束排除只是在查询的WHERE子句包含约束的时候才生效。一个参数化的查询不会被优化，因为在运行时规划器不知道该参数会选择哪个分区。因此像CURRENT_DATE这样的函数必须避免。把分区键值和另外一个表的字段连接起来也不会得到优化。

2). 在CHECK约束里面要避免跨数据类型的比较，因为目前规划器会无法证明这样的条件为假。比如，下面的约束会在x是整数字段的时候可用，但是在x是一个bigint的时候不能用：

CHECK (x = 1) www.2cto.com

对于bigint字段，我们必须使用类似下面这样的约束：

CHECK (x = 1::bigint)

这个问题并不仅仅局限于bigint数据类型，它可能会发生在任何约束的缺省数据类型与其比较的字段的数据类型不匹配的场合。在提交的查询里的跨数据类型的比较通常是OK的，只是不能在CHECK条件里。

3). 在主表上的UPDATE和DELETE命令并不执行约束排除。