Re: [PROPOSAL] Expand OR clauses in joins to UNION ALL paths

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

In response to

Browse pgsql-hackers by date

  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