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
Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation |
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> 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 по дате отправления: