From d007a95055b9b649b74b5d25aa4d2b46f3eca21c Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 23 Jul 2005 21:05:48 +0000 Subject: Simple constraint exclusion. For now, only child tables of inheritance scans are candidates for exclusion; this should be fixed eventually. Simon Riggs, with some help from Tom Lane. --- doc/src/sgml/runtime.sgml | 52 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 51 insertions(+), 1 deletion(-) (limited to 'doc/src') diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 4cae3fa894c..4f24a6e8762 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1,5 +1,5 @@ @@ -2278,6 +2278,56 @@ archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows + + enable_constraint_exclusion (boolean) + + constraint exclusion + + + enable_constraint_exclusion configuration parameter + + + + Enables or disables the query planner's use of table constraints. + The default is off. + + + + When this parameter is on, the planner compares query + conditions to table CHECK constraints, and omits scanning tables + for which the conditions contradict the constraints. (Presently + this is done only for child tables of inheritance scans.) For + example: + + +CREATE TABLE parent(key integer, ...); +CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent); +CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent); +... +SELECT * FROM parent WHERE key = 2400; + + + With constraint exclusion enabled, this SELECT will not scan + child1000 at all. This can improve performance when + inheritance is used to build partitioned tables. + + + + Currently, enable_constraint_exclusion defaults to + off, because it creates a risk of wrong answers when + query plans are cached: if a table constraint is changed or dropped, + the previously generated plan may now be wrong, and there is no + built-in mechanism to force re-planning. (This deficiency will + probably be addressed in a future + PostgreSQL release.) Another reason + for keeping it off is that the constraint checks are relatively + expensive to make, and in many circumstances will yield no savings. + It is recommended to turn this on only if you are actually using + partitioned tables designed to take advantage of the feature. + + + + from_collapse_limit (integer) -- cgit v1.2.3