Re: Hash Semi Join 5,000-50,000x slower on PG18 vs PG17 with 10+ equality columns and NULL values (identical plan, no spill)

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Dan Stefura <dstefura(at)bluecatnetworks(dot)com>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Hash Semi Join 5,000-50,000x slower on PG18 vs PG17 with 10+ equality columns and NULL values (identical plan, no spill)
Date: 2026-07-31 11:33:50
Message-ID: CAApHDvpZHt_igUK28xmCvve7yJJhqKkGMSbHgNZ9AfMXSrd=wQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, 31 Jul 2026 at 09:06, Dan Stefura <dstefura(at)bluecatnetworks(dot)com>
wrote:

> Our workaround is to set enable_hashjoin=off for this specific query.
>

Thanks for the report.

Another workaround that would be possible if it's only that one column that
can be NULL would be to put that one last in the join condition. The bug
was triggered because the NULL value wasn't last, and if it had been last,
then it wouldn't have triggered the bug. However, if you can't guarantee
that some other column won't be NULL, then enable_hashjoin=off is the safer
option until the minor version is released.

David

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Matheus Alcantara 2026-07-31 11:48:29 Re: BUG #19572: Redundant predicate changes JIT decision and causes an 18x performance difference
Previous Message David Rowley 2026-07-31 11:29:55 Re: Hash Semi Join 5,000-50,000x slower on PG18 vs PG17 with 10+ equality columns and NULL values (identical plan, no spill)