database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Create a third option named "partition" for constraint_exclusion, and make it

Browse Source 
the default.  This setting enables constraint exclusion checks only for
appendrel members (ie, inheritance children and UNION ALL arms), which are
the cases in which constraint exclusion is most likely to be useful.  Avoiding
the overhead for simple queries that are unlikely to benefit should bring
the cost down to the point where this is a reasonable default setting.
Per today's discussion.
This commit is contained in:
Tom Lane
2009-01-07 22:40:49 +00:00
parent 12dcf7bb75
commit 445ce15702
7 changed files with 92 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.202 2009/01/07 12:21:47 mha Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.203 2009/01/07 22:40:48 tgl Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -2145,7 +2145,7 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows
</varlistentry>
<varlistentry id="guc-constraint-exclusion" xreflabel="constraint_exclusion">
<term><varname>constraint_exclusion</varname> (<type>boolean</type>)</term>
<term><varname>constraint_exclusion</varname> (<type>enum</type>)</term>
<indexterm>
<primary>constraint exclusion</primary>
</indexterm>
@ -2155,14 +2155,20 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows
<listitem>
<para>
Enables or disables the query planner's use of table constraints to
optimize queries. The default is <literal>off</>.
optimize queries.
The allowed values of <varname>constraint_exclusion</> are
<literal>on</> (examine constraints for all tables),
<literal>off</> (never examine constraints), and
<literal>partition</> (examine constraints only for inheritance child
tables and <literal>UNION ALL</> subqueries).
<literal>partition</> is the default setting.
</para>
<para>
When this parameter is <literal>on</>, the planner compares
query conditions with table <literal>CHECK</> constraints, and
omits scanning tables for which the conditions contradict the
constraints. For example:
When this parameter allows it for a particular table, the planner
compares query conditions with the table's <literal>CHECK</>
constraints, and omits scanning tables for which the conditions
contradict the constraints. For example:
<programlisting>
CREATE TABLE parent(key integer, ...);
@ -2179,17 +2185,17 @@ SELECT * FROM parent WHERE key = 2400;
</para>
<para>
Currently, <varname>constraint_exclusion</> is disabled by
default because the constraint checks are relatively
expensive, 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.
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.
</para>
<para>
Refer to <xref linkend="ddl-partitioning"> for more information
on using constraint exclusion and partitioning.
Refer to <xref linkend="ddl-partitioning-constraint-exclusion"> for
more information on using constraint exclusion and partitioning.
</para>
</listitem>
</varlistentry>

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

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.83 2008/09/08 00:47:40 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.84 2009/01/07 22:40:49 tgl Exp $ -->
<chapter id="ddl">
<title>Data Definition</title>
@ -2135,7 +2135,7 @@ VALUES ('New York', NULL, NULL, 'NY');
an existing inheritance hierarchy, be careful to grant all the needed
permissions on it.
</para>
<para>
A serious limitation of the inheritance feature is that indexes (including
unique constraints) and foreign key constraints only apply to single
@ -2394,9 +2394,9 @@ CHECK ( outletID BETWEEN 200 AND 300 )
<listitem>
<para>
Ensure that the <xref linkend="guc-constraint-exclusion">
configuration
parameter is enabled in <filename>postgresql.conf</>. Without
this, queries will not be optimized as desired.
configuration parameter is not disabled in
<filename>postgresql.conf</>.
If it is, queries will not be optimized as desired.
</para>
</listitem>
@ -2698,7 +2698,7 @@ SELECT count(*) FROM measurement WHERE logdate &gt;= DATE '2008-01-01';
<para>
You can use the <command>EXPLAIN</> command to show the difference
between a plan with <varname>constraint_exclusion</> on and a plan
with it off. A typical default plan for this type of table setup is:
with it off. A typical unoptimized plan for this type of table setup is:
<programlisting>
SET constraint_exclusion = off;
@ -2725,7 +2725,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate &gt;= DATE '2008-01-01';
full-table sequential scans, but the point here is that there
is no need to scan the older partitions at all to answer this query.
When we enable constraint exclusion, we get a significantly
reduced plan that will deliver the same answer:
cheaper plan that will deliver the same answer:
<programlisting>
SET constraint_exclusion = on;
@ -2751,6 +2751,17 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate &gt;= DATE '2008-01-01';
be helpful in the latter case but not the former.
</para>
<para>
The default (and recommended) setting of
<xref linkend="guc-constraint-exclusion"> is actually neither
<literal>on</> nor <literal>off</>, but an intermediate setting
called <literal>partition</>, which causes the technique to be
applied only to queries that are likely to be working on partitioned
tables. The <literal>on</> setting causes the planner to examine
<literal>CHECK</> constraints in all queries, even simple ones that
are unlikely to benefit.
</para>
</sect2>
<sect2 id="ddl-partitioning-alternatives">
@ -2817,7 +2828,7 @@ UNION ALL SELECT * FROM measurement_y2008m01;
<sect2 id="ddl-partitioning-caveats">
<title>Caveats</title>
<para>
The following caveats apply to partitioned tables:
<itemizedlist>

6
doc/src/sgml/textsearch.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/textsearch.sgml,v 1.46 2008/10/17 18:05:19 teodor Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/textsearch.sgml,v 1.47 2009/01/07 22:40:49 tgl Exp $ -->
<chapter id="textsearch">
<title id="textsearch-title">Full Text Search</title>
@ -3254,8 +3254,8 @@ SELECT plainto_tsquery('supernovae stars');
<para>
Partitioning of big collections and the proper use of GiST and GIN indexes
allows the implementation of very fast searches with online update.
Partitioning can be done at the database level using table inheritance
and <varname>constraint_exclusion</>, or by distributing documents over
Partitioning can be done at the database level using table inheritance,
or by distributing documents over
servers and collecting search results using the <filename>contrib/dblink</>
extension module. The latter is possible because ranking functions use
only local information.