From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jinhui(dot)lai(at)qq(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation |
Date: | 2025-09-20 21:19:22 |
Message-ID: | 2510592.1758403162@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2025-09-20 22:54:54 | Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation |
Previous Message | PG Bug reporting form | 2025-09-20 16:08:11 | BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation |