From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 26 Mar 2007 01:41:57 +0000 (+0000)
Subject: Remove assertion that constraint_exclusion risks wrong answers if
X-Git-Tag: REL8_3_BETA1~963
X-Git-Url: http://git.postgresql.org/gitweb/?a=commitdiff_plain;h=287ed68dd2a8f0be6f10f6bd373e4c9c3887b821;p=postgresql.git

Remove assertion that constraint_exclusion risks wrong answers if
table constraints are changed; this is no longer true now that we
have a plan invalidation mechanism.
---

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index fab7cc4b0db..07d1a879b3f 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.117 2007/03/22 15:46:56 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.118 2007/03/26 01:41:57 tgl Exp $ -->
 
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -2140,13 +2140,7 @@ SELECT * FROM parent WHERE key = 2400;
 
        <para>
         Currently, <varname>constraint_exclusion</> is disabled by
-        default because it risks incorrect results if query plans are
-        cached &mdash; if a table constraint is changed or dropped,
-        the previously generated plan might now be wrong, and there is
-        no built-in mechanism to force re-planning.  (This deficiency
-        will probably be addressed in a future
-        <productname>PostgreSQL</> release.)  Another reason for
-        keeping it off is that the constraint checks are relatively
+        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