ExecHashRemoveNextSkewBucket must physically copy tuples to main hashtable.
Commit 45f6240a8fa9d355 added an assumption in ExecHashIncreaseNumBatches
and ExecHashIncreaseNumBuckets that they could find all tuples in the main
hash table by iterating over the "dense storage" introduced by that patch.
However, ExecHashRemoveNextSkewBucket continued its old practice of simply
re-linking deleted skew tuples into the main table's hashchains. Hence,
such tuples got lost during any subsequent increase in nbatch or nbuckets,
and would never get joined, as reported in bug #13908 from Seth P.
I (tgl) think that the aforesaid commit has got multiple design issues
and should be reworked rather completely; but there is no time for that
right now, so band-aid the problem by making ExecHashRemoveNextSkewBucket
physically copy deleted skew tuples into the "dense storage" arena.
The added test case is able to exhibit the problem by means of fooling the
planner with a WHERE condition that it will underestimate the selectivity
of, causing the initial nbatch estimate to be too small.
Tomas Vondra and Tom Lane. Thanks to David Johnston for initial
investigation into the bug report.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/f867ce5518202a4e625dc41b7036fec47ee0e09e
Modified Files
--------------
src/backend/executor/nodeHash.c | 15 +++++++++++++--
src/test/regress/expected/join.out | 28 ++++++++++++++++++++++++++++
src/test/regress/sql/join.sql | 16 ++++++++++++++++
3 files changed, 57 insertions(+), 2 deletions(-)