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

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: andrew(at)supernews(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1753: Query Optimizer does not work well with libpg
Date: 2005-07-06 03:09:39
Message-ID: 42CB4B73.9020500@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Satoshi Nagayasu 2005-07-06 08:59:24 Creating trigger function with argument(s) gets backend crash.
Previous Message Tom Lane 2005-07-06 02:48:10 Re: BUG #1753: Query Optimizer does not work well with libpg