database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Clean up handling of constraint_exclusion and enable_partition_pruning.

Browse Source 
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
This commit is contained in:
Tom Lane
2019-04-30 15:03:35 -04:00
parent 14323493dd
commit 11ea45ffec
6 changed files with 177 additions and 64 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
doc/src/sgml/config.sgml
View File

@ -4410,10 +4410,11 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
The allowed values of <varname>constraint_exclusion</varname> are
<literal>on</literal> (examine constraints for all tables),
<literal>off</literal> (never examine constraints), and
<literal>partition</literal> (examine constraints only for inheritance child
tables and <literal>UNION ALL</literal> subqueries).
<literal>partition</literal> (examine constraints only for inheritance
child tables and <literal>UNION ALL</literal> subqueries).
<literal>partition</literal> is the default setting.
It is often used with inheritance tables to improve performance.
It is often used with traditional inheritance trees to improve
performance.
</para>
<para>
@ -4437,15 +4438,19 @@ SELECT * FROM parent WHERE key = 2400;
<para>
Currently, constraint exclusion is enabled by default
only for cases that are often used to implement table partitioning via
inheritance tables. Turning it on for all tables imposes extra
inheritance trees. 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
inheritance partitioned tables you might prefer to turn it off entirely.
tables that are partitioned using traditional inheritance, you might
prefer to turn it off entirely. (Note that the equivalent feature for
partitioned tables is controlled by a separate parameter,
<xref linkend="guc-enable-partition-pruning"/>.)
</para>
<para>
Refer to <xref linkend="ddl-partitioning-constraint-exclusion"/> for
more information on using constraint exclusion and partitioning.
more information on using constraint exclusion to implement
partitioning.
</para>
</listitem>
</varlistentry>

21
doc/src/sgml/ddl.sgml
View File

@ -3918,22 +3918,11 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate &gt;= DATE '2008-01-01';
<note>
<para>
Currently, pruning of partitions during the planning of an
<command>UPDATE</command> or <command>DELETE</command> command is
implemented using the constraint exclusion method (however, it is
controlled by the <literal>enable_partition_pruning</literal> rather than
<literal>constraint_exclusion</literal>) &mdash; see the following section
for details and caveats that apply.
</para>
<para>
Also, execution-time partition pruning currently only occurs for the
<literal>Append</literal> node type, not <literal>MergeAppend</literal>.
</para>
<para>
Both of these behaviors are likely to be changed in a future release
of <productname>PostgreSQL</productname>.
Execution-time partition pruning currently only occurs for the
<literal>Append</literal> node type, not
for <literal>MergeAppend</literal> or <literal>ModifyTable</literal>
nodes. That is likely to be changed in a future release of
<productname>PostgreSQL</productname>.
</para>
</note>
</sect2>