| From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Ayoub Kazar <ayoub(dot)kazar(at)data-bene(dot)io>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PROPOSAL] Expand OR clauses in joins to UNION ALL paths |
| Date: | 2026-10-09 06:11:17 |
| Message-ID: | 5add3e36-546a-46ae-934b-a87216a10a7a@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> The transformation is not always beneficial. Here's an example:
>>
>> SELECT o.*
>> FROM orders o
>> JOIN customers c ON o.customer_id = c.id
>> WHERE o.status = 'returned' -- very selective: 1k rows
>> OR c.tier = 'standard'; -- very unselective: 900k of 1M customers
>>
>> When one condition is very selective a NLJ on the table with the more
>> selective condition is actually pretty efficient.
>>
>> Do you unconditionally apply the transformation, or do you have
>> heuristics to only do it if it likely pays off?
>
> No everything is planned like any other path, each arm in the OR gets
> fully planned alone, then UNIONed ALL together, cost is recalculated on
> this new Append path, so its cost based, not a rule.
Ah, that's cool!
I was thinking about it like a rewrite happening post-parsing /
pre-planning.
--
David Geier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-10-09 06:35:24 | Re: Publication DDL can race with a concurrent UPDATE |
| Previous Message | Chao Li | 2026-10-09 06:05:00 | Re: [PG19] Three bugs with a CHECK constraint that only the child enforces |