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

Add a caveat pointing out that constraint exclusion doesn't work with

Browse Source 
constraints the planner is unable to disprove, hence simple btree-compatible
conditions should be used.  We've seen people try to get cute with stuff
like date_part(something) = something at least twice now.  Even if we
wanted to try to teach predtest.c about the properties of date_part,
most of the useful variants aren't immutable so nothing could be proved.
This commit is contained in:
Tom Lane
2007-06-20 23:11:38 +00:00
parent 8f3d07764f
commit 4c2d3ccf8a
1 changed files with 17 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.75 2007/05/15 19:43:50 neilc Exp $ --> <!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.76 2007/06/20 23:11:38 tgl Exp $ -->
<chapter id="ddl"> <chapter id="ddl">
<title>Data Definition</title> <title>Data Definition</title>
@ -2778,7 +2778,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate &gt;= DATE '2006-01-01';
<para> <para>
Constraint exclusion only works when the query's <literal>WHERE</> Constraint exclusion only works when the query's <literal>WHERE</>
clause contains constants. A parameterized query will not be clause contains constants. A parameterized query will not be
optimized, since the planner cannot know what partitions the optimized, since the planner cannot know which partitions the
parameter value might select at run time. For the same reason, parameter value might select at run time. For the same reason,
<quote>stable</> functions such as <function>CURRENT_DATE</function> <quote>stable</> functions such as <function>CURRENT_DATE</function>
must be avoided. must be avoided.
@ -2787,9 +2787,21 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate &gt;= DATE '2006-01-01';
<listitem> <listitem>
<para> <para>
All constraints on all partitions of the master table are considered for Keep the partitioning constraints simple, else the planner may not be
constraint exclusion, so large numbers of partitions are likely to able to prove that partitions don't need to be visited. Use simple
increase query planning time considerably. equality conditions for list partitioning, or simple
range tests for range partitioning, as illustrated in the preceding
examples. A good rule of thumb is that partitioning constraints should
contain only comparisons of the partitioning column(s) to constants
using btree-indexable operators.
</para>
</listitem>
<listitem>
<para>
All constraints on all partitions of the master table are examined
during constraint exclusion, so large numbers of partitions are likely
to increase query planning time considerably.
</para> </para>
</listitem> </listitem>