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>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Constraint exclusion only works when the query's <literal>WHERE</>
|
Constraint exclusion only works when the query's <literal>WHERE</>
|
||||||
clause contains constants. A parameterized query will not be
|
clause contains constants (or externally supplied parameters).
|
||||||
optimized, since the planner cannot know which partitions the
|
For example, a comparison against a non-immutable function such as
|
||||||
parameter value might select at run time. For the same reason,
|
<function>CURRENT_TIMESTAMP</function> cannot be optimized, since the
|
||||||
<quote>stable</> functions such as <function>CURRENT_DATE</function>
|
planner cannot know which partition the function value might fall
|
||||||
must be avoided.
|
into at run time.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user