Re: Do not scan index in right table if condition for left join evaluates to false using columns in left table

Andrei Lepikhov <lepihov@gmail.com>

From: Andrei Lepikhov <lepihov@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Илья Жарков <izharkov1243@gmail.com>, pgsql-hackers@lists.postgresql.org, p.petrov@postgrespro.ru
Date: 2024-12-08T08:44:23Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Rewrite maybe_reread_subscription() comment

On 8/12/2024 09:52, Andres Freund wrote:
>> I think avoiding touching a hash table and an index under MergeJoin can also
>> be beneficial.
> 
> How would you get significant wins for mergejoins? You need to go through both
> inner and outer anyway?
In my mind, this trick can be designed for specific cases like sales 
tables, as illustrated before and used by well-rounded developers. I'm 
not sure that such optimisation would be profitable in general. My point 
is that the sales database has lots of categories, and when requesting 
product descriptions, we will not necessarily touch all the categories - 
in that case, the one-sided clause could allow us to avoid scanning some 
tables at all. Am I wrong?
BTW, may it be used in SEMI JOIN cases?

-- 
regards, Andrei Lepikhov