Re: Improve hash join's handling of tuples with null join keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Improve hash join's handling of tuples with null join keys
Date: 2025-05-06 00:58:31
Message-ID: 3073503.1746493111@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(at)vondra(dot)me> writes:
> My personal experience is that the growEnabled heuristics is overly
> sensitive, and probably does not trigger very often.

Yeah, it would be good to make it not quite all-or-nothing.

> But more importantly, wasn't the issue discussed in [1] about parallel
> hash joins?

I'm not clear on that either; it seemed that the OP was able to
trigger it in some non-parallel cases too. But we don't have a
reproducer so I can't say for sure. Building a reproducer would
be a useful exercise for testing this. There might well be some
parallel-specific misbehavior that would be worth ameliorating
independently of this work, in case of a lot of non-null duplicate
keys.

>> This passes check-world, and I've extended a couple of existing test
>> cases to ensure that the new code paths are exercised. I've not done
>> any real performance testing, though.

> Are you planning to? If not, I can try to collect some numbers, but I
> can't promise that before pgconf.dev.

If you have time after the conference, please feel free.

> BTW do you consider this to be a bugfix for PG18? Or would it have to
> wait for PG19 at this point?

This has been like this forever I suspect --- certainly for as long
as we've had PHJ, and probably longer. So I'm seeing it as new work
for v19, not something we'd attempt to back-patch.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Schneider 2025-05-06 02:44:03 Re: queryId constant squashing does not support prepared statements
Previous Message Tatsuo Ishii 2025-05-06 00:53:51 Re: Row pattern recognition