Re: BUG #1753: Query Optimizer does not work well with libpg

Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> 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