mirror of
https://github.com/postgres/postgres.git
synced 2025-04-24 10:47:04 +03:00
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.
This commit is contained in:
parent
b33f611682
commit
6e2e12c947
@ -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>
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user