如何处理大量数据(三)

部分或者全部分区可能会使用索引扫描而不是全表扫描， 不过这里要表达的意思是我们没有必要扫描旧的分区旧可以回答这个查询。 在我们打开约束排除之后，我们可以得到生成同样回答的明显节省的规划：

SET constraint_exclusion = on; EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2006-01-01'; QUERY PLAN ----------------------------------------------------------------------------------------------- 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 约束驱动，而不会由索引驱动。 因此，在键字字段上定义索引是没有必要的。 在给出的分区上是否需要建立索引取决于那些扫描该分区的查询通常是扫描该分区的一大部分还是只是一小部分。 对于后者，索引通常都有帮助，对于前者则没有什么好处。

还有下面的注意：

约束排除只是在查询的 WHERE 子句包含约束的时候才生效。 一个参数化的查询不会被优化，因为在运行时规划器不知道改参数会选择哪个分区。 由于某些原因，像 CURRENT_DATE 这样的"稳定的（stable）"函数必须避免。 把分区键字和另外一个表的字段连接起来也不会得到优化。

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

CHECK ( x = 1 )

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

CHECK ( x = 1::bigint )

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

目前，在主表上的 UPDATE 和 DELETE 命令并不执行约束排除。

主表的所有分区上面的所有约束都认为是约束排除了的，因此，大量的分区会显著增加查询规划的时间。

别忘记你仍然需要为每个分区独立运行 ANALYZE。 类似下面的命令

ANALYZE measurement;

是只会处理主表的。

UNION ALL SELECT * FROM measurement_yy06mm01;

不过，约束排除目前还不支持用这种方式定义的分区。 还有，重建试图也给增加和删除数据集里面的独立分区增加了额外的步骤。