Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation
Дата
Msg-id
2510592.1758403162@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation PG Bug reporting form <noreply@postgresql.org>
Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation Christophe Pettus <xof@thebuild.com>
Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation Vik Fearing <vik@postgresfriends.org>
PG Bug reporting form  writes:
> However, the optimizer fails to reorder the expressions in the WHERE clause
> for the second query. You can observe this from the second row in the plan:
> "Filter: (EXISTS(SubPlan 1) OR (c0 > 0))"
> A more optimal strategy would be for PG to use its cost model to reorder
> expressions, prioritizing the evaluation of less expensive operations first.

We do do that at the top AND level (cf. order_qual_clauses())
but we have not bothered for OR clauses.

The whole exercise is pretty questionable really, considering how weak
our cost model for expressions is.  We could easily end up pessimizing
a clause that the user had put into carefully-selected order.
While we've not gotten a huge amount of push-back about the top-level
re-ordering, there's been some complaints.  So I'm not eager to
propagate the idea further down.

			regards, tom lane


В списке pgsql-bugs по дате отправления
От: PG Bug reporting form
Дата:
От: Christophe Pettus
Дата:
FAQ