Skip to content

Commit ead31d1

Browse files
committed
Remove overly-pessimistic statement about constraint exclusion.
As of 9.2, constraint exclusion should work okay with prepared statements: the planner will try custom plans with actual values of the parameters, and observe that they are a lot cheaper than the generic plan, and thus never fall back to using the generic plan. Noted by Tatsuhito Kasahara.
1 parent d333773 commit ead31d1

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

doc/src/sgml/ddl.sgml

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -2964,11 +2964,11 @@ ANALYZE measurement;
29642964
<listitem>
29652965
<para>
29662966
Constraint exclusion only works when the query's <literal>WHERE</>
2967-
clause contains constants. A parameterized query will not be
2968-
optimized, since the planner cannot know which partitions the
2969-
parameter value might select at run time. For the same reason,
2970-
<quote>stable</> functions such as <function>CURRENT_DATE</function>
2971-
must be avoided.
2967+
clause contains constants (or externally supplied parameters).
2968+
For example, a comparison against a non-immutable function such as
2969+
<function>CURRENT_TIMESTAMP</function> cannot be optimized, since the
2970+
planner cannot know which partition the function value might fall
2971+
into at run time.
29722972
</para>
29732973
</listitem>
29742974

0 commit comments

Comments
 (0)