11<!--
2- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.33 2005/10/26 12:55:07 momjian Exp $
2+ $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.34 2005/11/01 23:19:05 neilc Exp $
33-->
44<chapter Id="runtime-config">
55 <title>Server Configuration</title>
@@ -1974,11 +1974,11 @@ archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
19741974 </para>
19751975
19761976 <para>
1977- When this parameter is <literal>on</>, the planner compares query
1978- conditions with table CHECK constraints, and omits scanning tables
1979- where the conditions contradict the constraints. (Presently
1980- this is done only for child tables of inheritance scans.) For
1981- example:
1977+ When this parameter is <literal>on</>, the planner compares
1978+ query conditions with table<literal> CHECK</> constraints, and
1979+ omits scanning tables where the conditions contradict the
1980+ constraints. (Presently this is done only for child tables of
1981+ inheritance scans.) For example:
19821982
19831983<programlisting>
19841984CREATE TABLE parent(key integer, ...);
@@ -1988,23 +1988,30 @@ CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
19881988SELECT * FROM parent WHERE key = 2400;
19891989</programlisting>
19901990
1991- With constraint exclusion enabled, this SELECT will not scan
1992- <structname>child1000</> at all. This can improve performance when
1993- inheritance is used to build partitioned tables.
1991+ With constraint exclusion enabled, this <command>SELECT</>
1992+ will not scan <structname>child1000</> at all. This can
1993+ improve performance when inheritance is used to build
1994+ partitioned tables.
19941995 </para>
19951996
19961997 <para>
1997- Currently, <varname>constraint_exclusion</>defaults to
1998- <literal>off</>, because it risks incorrect results if
1999- query plans are cached--- if a table constraint is changed or dropped,
2000- the previously generated plan might now be wrong, and there is no
2001- built-in mechanism to force re-planning. (This deficiency will
2002- probably be addressed in a future
2003- <productname>PostgreSQL</productname > release.) Another reason
2004- for keeping it off is that the constraint checks are relatively
1998+ Currently, <varname>constraint_exclusion</>is disabled by
1999+ default because it risks incorrect results if query plans are
2000+ cached— if a table constraint is changed or dropped,
2001+ the previously generated plan might now be wrong, and there is
2002+ no built-in mechanism to force re-planning. (This deficiency
2003+ will probably be addressed in a future
2004+ <productname>PostgreSQL</> release.) Another reason for
2005+ keeping it off is that the constraint checks are relatively
20052006 expensive, and in many circumstances will yield no savings.
2006- It is recommended to turn this on only if you are actually using
2007- partitioned tables designed to take advantage of the feature.
2007+ It is recommended to turn this on only if you are actually
2008+ using partitioned tables designed to take advantage of the
2009+ feature.
2010+ </para>
2011+
2012+ <para>
2013+ Refer to <xref linkend="ce-partitioning"> for more information
2014+ on using constraint exclusion and partitioning.
20082015 </para>
20092016 </listitem>
20102017 </varlistentry>
