Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
>
>>Sure, expression optimization is less aggressive, but is that on its own
>>really going to produce a 100-fold difference in query execution?
>
>
> It's certainly possible, depending on query details.
Andrew pointed out in some offlist discussion that it's actually more
than just expression optimization via eval_const_expressions; there are
some other cases where the tree is transformed differently if you have a
Const vs. Param in ways that estimate_expression_value() doesn't deal with:
- predicate_implied_by_simple_clause can remove parts of an expression
based on the actual (not estimated) values involved;
- match_special_index_operator manipulates LIKE/regexp/etc expressions
based on the actual patterns provided;
- LIMIT/OFFSET modifications to query cost only kick in with Consts.
I can't see any simple way to fix the first two since they change the
meaning of the expression, but the LIMIT/OFFSET query cost code could in
theory use estimate_expression_value().
-O
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
