Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

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

Andres Freund <andres@anarazel.de> writes:
> On 2024-12-08 09:23:42 +0700, Andrei Lepikhov 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?

Yeah, sounds like nonsense to me too.  The reason this can be a win
for nestloop is that we perform a new scan of the inner relation
for each outer row, and if we can skip an inner scan altogether
then we're ahead.  But mergejoin and hashjoin only scan each input
once anyway, so I see no opportunity to save any scan work.

It's barely possible that this is interesting for hash join
because you could save scanning a hash list ... but frankly
I don't believe there could be enough win there to justify
additional mechanism.  Hash join is in a world of hurt already
if there are lots of duplicate hash codes.

			regards, tom lane