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

Поиск
Список
Период
Сортировка
От Oliver Jowett
Тема Re: BUG #1753: Query Optimizer does not work well with libpg
Дата
Msg-id 42CB4B73.9020500@opencloud.com
обсуждение исходный текст
Ответ на Re: BUG #1753: Query Optimizer does not work well with libpg  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #1753: Query Optimizer does not work well with libpg
Следующее
От: Thanh Q Lam
Дата:
Сообщение: Error installing Postgres on Solaris 9