Re: Improve hash join's handling of tuples with null join keys
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chao Li <li.evan.chao@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2026-03-03T20:58:16Z
Lists: pgsql-hackers
Attachments
- v3-0001-Improve-hash-join-s-handling-of-tuples-with-null-.patch (text/x-diff) patch v3-0001
- v3-0002-Fix-tuple-counting-issues-in-hash-joins.patch (text/x-diff) patch v3-0002
I wrote: > Bug #19030 [1] seems to be a fresh report of the problem this patch > aims to solve. While answering that, I realized that the v2 patch > causes null-keyed inner rows to not be included in EXPLAIN ANALYZE's > report of the number of rows output by the Hash node. Now on the > one hand, what it's reporting is an accurate reflection of the > number of rows in the hash table, which perhaps is useful. On the > other hand, it's almost surely going to confuse users, and it's > different from the number we produced before. Should we try to > preserve the old behavior here? (I've not looked at what code > changes would be needed for that.) I got around to looking at that finally. It's not terribly difficult to fix, but while figuring out which counters were used for what, I noticed a pre-existing bug: when ExecHashRemoveNextSkewBucket moves tuples into the main hash table from the skew hash table, it fails to adjust hashtable->skewTuples, meaning that subsequent executions of ExecHashTableInsert will have the wrong idea of how many tuples are in the main table. The error is probably not very large because the skew table is not supposed to be big relative to the main table, but still, it's wrong. So I tried to clean that up here. 0001 attached is the same patch as before (brought up to HEAD, but only line numbers change). 0002 is the new code to fix these tuple-counting issues. regards, tom lane
Commits
-
Improve hash join's handling of tuples with null join keys.
- 1811f1af98fb 19 (unreleased) landed