From a7f49252d2476cc5996b1e9dbb253cdc521fbb7f Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Mon, 22 Aug 2005 17:35:03 +0000
Subject: enable_constraint_exclusion => constraint_exclusion

Also improve wording.
---
 doc/src/FAQ/TODO.html     |  4 ++--
 doc/src/sgml/runtime.sgml | 26 +++++++++++++-------------
 2 files changed, 15 insertions(+), 15 deletions(-)

(limited to 'doc/src')

diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index a2b70a78bc9..edd160c3f77 100644
--- a/doc/src/FAQ/TODO.html
+++ b/doc/src/FAQ/TODO.html
@@ -355,7 +355,7 @@ first.
 </p>
   </li><li>Add GUC to issue notice about queries that use unjoined tables
   </li><li>Allow EXPLAIN to identify tables that were skipped because of 
-  enable_constraint_exclusion
+  constraint_exclusion
   </li><li>Allow EXPLAIN output to be more easily processed by scripts
   </li><li>CREATE
   <ul>
@@ -694,7 +694,7 @@ first.
   </li><li>Allow the creation of indexes with mixed ascending/descending specifiers
   </li><li>-<em>Fix incorrect rtree results due to wrong assumptions about "over"</em>
   operator semantics
-  </li><li>Allow enable_constraint_exclusion to work for UNIONs like it does for
+  </li><li>Allow constraint_exclusion to work for UNIONs like it does for
   inheritance, and allow it to work for UPDATE and DELETE queries
   </li><li>GIST
   <ul>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 0966b5105e5..a699e0096b2 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.346 2005/08/21 03:39:26 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.347 2005/08/22 17:34:56 momjian Exp $
 -->
 
 <chapter Id="runtime">
@@ -2352,24 +2352,24 @@ archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
       </listitem>
      </varlistentry>
 
-     <varlistentry id="guc-enable-constraint-exclusion" xreflabel="enable_constraint_exclusion">
-      <term><varname>enable_constraint_exclusion</varname> (<type>boolean</type>)</term>
+     <varlistentry id="guc-constraint-exclusion" xreflabel="constraint_exclusion">
+      <term><varname>constraint_exclusion</varname> (<type>boolean</type>)</term>
       <indexterm>
        <primary>constraint exclusion</primary>
       </indexterm>
       <indexterm>
-       <primary><varname>enable_constraint_exclusion</> configuration parameter</primary>
+       <primary><varname>constraint_exclusion</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
-        Enables or disables the query planner's use of table constraints.
-        The default is <literal>off</>.
+        Enables or disables the query planner's use of table constraints to
+        limit table access.  The default is <literal>off</>.
        </para>
 
        <para>
         When this parameter is <literal>on</>, the planner compares query
-        conditions to table CHECK constraints, and omits scanning tables
-        for which the conditions contradict the constraints.  (Presently
+        conditions with table CHECK constraints, and omits scanning tables
+        where the conditions contradict the constraints.  (Presently
         this is done only for child tables of inheritance scans.)  For
         example:
 
@@ -2387,15 +2387,15 @@ SELECT * FROM parent WHERE key = 2400;
        </para>
 
        <para>
-        Currently, <varname>enable_constraint_exclusion</> defaults to
-        <literal>off</>, because it creates a risk of wrong answers when
-        query plans are cached: if a table constraint is changed or dropped,
-        the previously generated plan may now be wrong, and there is no
+        Currently, <varname>constraint_exclusion</> defaults to
+        <literal>off</>, because it risks incorrect results if
+        query plans are cached --- 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</productname> release.)  Another reason
         for keeping it off is that the constraint checks are relatively
-        expensive to make, and in many circumstances will yield no savings.
+        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.
        </para>
-- 
cgit v1.2.3