Controls the query planner's use of table constraints to optimize queries. The allowed values of
on (examine constraints for all tables),
off (never examine constraints), and
partition (examine constraints only for inheritance child tables and
UNION ALL subqueries).
partition is the default setting. It is often used with inheritance and partitioned tables to improve performance.
When this parameter allows it for a particular table, the planner compares query conditions with the table's
CHECK constraints, and omits scanning tables for which the conditions contradict the constraints. 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, improving performance.
Currently, constraint exclusion is enabled by default only for cases that are often used to implement table partitioning. Turning it on for all tables imposes extra planning overhead that is quite noticeable on simple queries, and most often will yield no benefit for simple queries. If you have no partitioned tables you might prefer to turn it off entirely.
Refer to ddl-partitioning-constraint-exclusion for more information on using constraint exclusion and partitioning.
- PostgreSQL: when we should set constraint_exclusion off?
- PostgreSQL constraint exclusion not working with subquery SELECT IN
- Terrible performance degradation in postgreSQL when i created too many partitions
- PostgreSQL Partitioning. Constraint Exclusion not kicking in on SELECT
- Why aren'y my CHECK CONSTRAINTS on child tables being utilized by the planner to reduce the size of the plan?
- Re: Should we add GUCs to allow partition pruning to be disabled?
- Re: constraint exclusion and nulls in IN (..) clause
- RE: Planning time of Generic plan for a table partitioned into a lot
- Re: Planning time of Generic plan for a table partitioned into a lot
- Re: documentation fixes for partition pruning, round three