Re: BUG #1753: Query Optimizer does not work well with libpg - Mailing list pgsql-bugs

From Oliver Jowett
Subject Re: BUG #1753: Query Optimizer does not work well with libpg
Date
Msg-id 42CB4B73.9020500@opencloud.com
Whole thread Raw
In response to Re: BUG #1753: Query Optimizer does not work well with libpg  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1753: Query Optimizer does not work well with libpg
Next
From: Thanh Q Lam
Date:
Subject: Error installing Postgres on Solaris 9