mirror of
https://github.com/postgres/postgres.git
synced 2025-05-02 11:44:50 +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
d333773127
commit
ead31d1a72
@ -2964,11 +2964,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