| From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
|---|---|
| To: | Christophe Pettus <xof(at)thebuild(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | jinhui(dot)lai(at)qq(dot)com, 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-21 09:09:02 |
| Message-ID: | f5ab4542-acfa-4939-a6aa-0e42b69bb46a@postgresfriends.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 21/09/2025 00:54, Christophe Pettus wrote:
>> On Sep 20, 2025, at 14:19, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
> And tangentially, doesn't the SQL standard make it implementation-defined if OR short-circuits or not?
>
Not that I can see. The only implementation-defined mention in <boolean
value expression> is:
"If the SQL-implementation supports Feature T101, “Enhanced nullability
determination”, and if BVE conforms to an implementation-defined (IE011)
rule that enables the SQL-implementation to correctly infer that, when
BVE is True, then X cannot be null, then BVE is a known-not-null
condition for X. "
--
Vik Fearing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jinhui Lai | 2025-09-21 16:05:34 | Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation |
| Previous Message | Tom Lane | 2025-09-20 23:19:03 | Re: BUG #19059: PostgreSQL fails to evaluate the cheaper expression first, leading to 45X performance degradation |