postgres.git / summary / log / commit / refs

commit    6e2e12c9477c3b48854433251ebca9709be3e87b
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Thu Aug 23 03:55:34 2012 +0000
First released in: 9.3.0, 9.2.0

    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.


 doc/src/sgml/ddl.sgml | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 013dc7c4dac..07bfc203ec7 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -2975,11 +2975,11 @@ ANALYZE measurement;
     <listitem>
      <para>
       Constraint exclusion only works when the query's <literal>WHERE</>
-      clause contains constants.  A parameterized query will not be
-      optimized, since the planner cannot know which partitions the
-      parameter value might select at run time.  For the same reason,
-      <quote>stable</> functions such as <function>CURRENT_DATE</function>
-      must be avoided.
+      clause contains constants (or externally supplied parameters).
+      For example, a comparison against a non-immutable function such as
+      <function>CURRENT_TIMESTAMP</function> cannot be optimized, since the
+      planner cannot know which partition the function value might fall
+      into at run time.
      </para>
     </listitem>
 


[parent: b33f611682d0]