|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.117 2007/03/22 15:46:56 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.118 2007/03/26 01:41:57 tgl Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter Id="runtime-config"> |
4 | 4 | <title>Server Configuration</title> |
@@ -2140,13 +2140,7 @@ SELECT * FROM parent WHERE key = 2400; |
2140 | 2140 |
|
2141 | 2141 | <para> |
2142 | 2142 | Currently, <varname>constraint_exclusion</> is disabled by |
2143 | | - default because it risks incorrect results if query plans are |
2144 | | - cached — if a table constraint is changed or dropped, |
2145 | | - the previously generated plan might now be wrong, and there is |
2146 | | - no built-in mechanism to force re-planning. (This deficiency |
2147 | | - will probably be addressed in a future |
2148 | | - <productname>PostgreSQL</> release.) Another reason for |
2149 | | - keeping it off is that the constraint checks are relatively |
| 2143 | + default because the constraint checks are relatively |
2150 | 2144 | expensive, and in many circumstances will yield no savings. |
2151 | 2145 | It is recommended to turn this on only if you are actually |
2152 | 2146 | using partitioned tables designed to take advantage of the |
|