Fix constraint exclusion to work in inherited UPDATE/DELETE queries

... in fact, it will be applied now in any query whatsoever.  I'm still
a bit concerned about the cycles that might be expended in failed proof
attempts, but given that CE is turned off by default, it's the user's
choice whether to expend those cycles or not.  (Possibly we should
change the simple bool constraint_exclusion parameter to something
more fine-grained?)

2 files changed, 7 insertions, 17 deletions

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 1de87b24414..0820c6cc9fb 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.45 2006/01/23 18:16:41 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.46 2006/02/04 23:03:19 tgl Exp $
 -->
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -1986,8 +1986,7 @@ archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
         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.  (Presently this is done only for child tables of
-        inheritance scans.)  For example:
+        constraints.  For example:
 
 <programlisting>
 CREATE TABLE parent(key integer, ...);
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index e6b694ed7bf..2342f8703ca 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.51 2005/12/23 00:38:03 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.52 2006/02/04 23:03:19 tgl Exp $ -->
 
 <chapter id="ddl">
  <title>Data Definition</title>
@@ -2179,7 +2179,7 @@ SELECT * from cities*;
 
    <para>
     <productname>PostgreSQL</productname> supports basic table
-    partitioning. This section describes why and how you can implement
+    partitioning. This section describes why and how to implement
     partitioning as part of your database design.
    </para>
 
@@ -2237,7 +2237,7 @@ SELECT * from cities*;
     table of a single parent table.  The parent table itself is normally
     empty; it exists just to represent the entire data set.  You should be
     familiar with inheritance (see <xref linkend="ddl-inherit">) before
-    attempting to implement partitioning.
+    attempting to set up partitioning.
    </para>
 
    <para>
@@ -2579,8 +2579,7 @@ UNION ALL SELECT * FROM measurement_yy05mm12
 UNION ALL SELECT * FROM measurement_yy06mm01;
 </programlisting>
 
-    However, constraint exclusion is currently not supported for
-    partitioned tables defined in this manner.  Also, the need to
+    However, the need to
     recreate the view adds an extra step to adding and dropping
     individual partitions of the dataset.
    </para>
@@ -2679,8 +2678,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2006-01-01';
       optimized, since the planner cannot know what partitions the
       parameter value might select at runtime.  For the same reason,
       <quote>stable</> functions such as <function>CURRENT_DATE</function>
-      must be avoided.  Joining the partition key to a column of another
-      table will not be optimized, either.
+      must be avoided.
      </para>
     </listitem>
 
@@ -2709,13 +2707,6 @@ CHECK ( x = 1::bigint )
 
     <listitem>
      <para>
-      <command>UPDATE</command> and <command>DELETE</command> commands
-      against the master table do not currently perform constraint exclusion.
-     </para>
-    </listitem>
-
-    <listitem>
-     <para>
       All constraints on all partitions of the master table are considered for
       constraint exclusion, so large numbers of partitions are likely to
       increase query planning time considerably.