Horton

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

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Илья Жарков <izharkov1243@gmail.com>, pgsql-hackers@lists.postgresql.org, p.petrov@postgrespro.ru
Date: 2024-12-08T02:52:20Z
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

Hi,

On 2024-12-08 09:23:42 +0700, Andrei Lepikhov wrote:
> To determine how difficult it could be, I wrote a prototype (very raw),
> which shows how it works in action and how many subsystems we have to touch.

Cool!


> Also, I wonder why you think it could work with NestLoop only.

It doesn't seem to apply to mergejoins. For hashjoins, it doesn't seem worth a
separate evaluation of a expression - something which has noticeable overhead
on its own - given that the cost of a lookup in the hashtable isn't
particularly high. Compare that to the nestloop case where you always need an
indexscan and often will have more complicated subtrees being executed
unnecessarily on the inner side.


> 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?

Greetings,

Andres Freund