pgsql: Clean up handling of constraint_exclusion and enable_partition_p

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Clean up handling of constraint_exclusion and enable_partition_p
Date: 2019-04-30 19:04:09
Message-ID: E1hLY2z-0003Sn-Ud@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Clean up handling of constraint_exclusion and enable_partition_pruning.

The interaction of these parameters was a bit confused/confusing,
and in fact v11 entirely misses the opportunity to apply partition
constraints when a partition is accessed directly (rather than
indirectly from its parent).

In HEAD, establish the principle that enable_partition_pruning controls
partition pruning and nothing else. When accessing a partition via its
parent, we do partition pruning (if enabled by enable_partition_pruning)
and then there is no need to consider partition constraints in the
constraint_exclusion logic. When accessing a partition directly, its
partition constraints are applied by the constraint_exclusion logic,
only if constraint_exclusion = on.

In v11, we can't have such a clean division of these GUCs' effects,
partly because we don't want to break compatibility too much in a
released branch, and partly because the clean coding requires
inheritance_planner to have applied partition pruning to a partitioned
target table, which it doesn't in v11. However, we can tweak things
enough to cover the missed case, which seems like a good idea since
it's potentially a performance regression from v10. This patch keeps
v11's previous behavior in which enable_partition_pruning overrides
constraint_exclusion for an inherited target table, though.

In HEAD, also teach relation_excluded_by_constraints that it's okay to use
inheritable constraints when trying to prune a traditional inheritance
tree. This might not be thought worthy of effort given that that feature
is semi-deprecated now, but we have enough infrastructure that it only
takes a couple more lines of code to do it correctly.

Amit Langote and Tom Lane

Discussion: https://postgr.es/m/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp
Discussion: https://postgr.es/m/29069.1555970894@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/e03ff739695cb731956763355e8e0f38c6905008

Modified Files
--------------
doc/src/sgml/config.sgml | 17 ++--
doc/src/sgml/ddl.sgml | 17 +---
src/backend/optimizer/plan/planner.c | 5 +-
src/backend/optimizer/util/plancat.c | 122 ++++++++++++++++----------
src/test/regress/expected/partition_prune.out | 42 +++++++++
src/test/regress/sql/partition_prune.sql | 20 +++++
6 files changed, 156 insertions(+), 67 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Julien Rouhaud 2019-04-30 21:41:55 Re: pgsql: Track block level checksum failures in pg_stat_database
Previous Message Bruce Momjian 2019-04-30 18:07:01 pgsql: doc: improve PG 12 to_timestamp()/to_date() wording