pgsql: Clean up handling of constraint_exclusion andenable_partition_p - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Clean up handling of constraint_exclusion andenable_partition_p
Date
Msg-id E1hLY2z-0003Sn-Ud@gemulon.postgresql.org
Whole thread Raw
List 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(-)


pgsql-committers by date:

Previous
From: Bruce Momjian
Date:
Subject: pgsql: doc: improve PG 12 to_timestamp()/to_date() wording
Next
From: Julien Rouhaud
Date:
Subject: Re: pgsql: Track block level checksum failures in pg_stat_database