mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Remove assertion that constraint_exclusion risks wrong answers if

Browse Source 
table constraints are changed; this is no longer true now that we
have a plan invalidation mechanism.
This commit is contained in:
Tom Lane 2007-03-26 01:41:57 +00:00
parent dc1b8cea93
commit 287ed68dd2
1 changed files with 2 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/sgml/config.sgml
View File

@ -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"> <chapter Id="runtime-config">
<title>Server Configuration</title> <title>Server Configuration</title>
@ -2140,13 +2140,7 @@ SELECT * FROM parent WHERE key = 2400;
<para> <para>
Currently, <varname>constraint_exclusion</> is disabled by Currently, <varname>constraint_exclusion</> is disabled by
default because it risks incorrect results if query plans are default because the constraint checks are relatively
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
expensive, 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 It is recommended to turn this on only if you are actually
using partitioned tables designed to take advantage of the using partitioned tables designed to take advantage of the