Thread: pgsql: Fix performance problems in multi-batch hash joins by ensuring
pgsql: Fix performance problems in multi-batch hash joins by ensuring
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message:
-----------
Fix performance problems in multi-batch hash joins by ensuring that we select
a well-randomized batch number even when given a poorly-randomized hash value.
This is a bit inefficient but seems the only practical solution given the
constraint that we can't change the hash functions in released branches.
Per report from Joseph Shraibman.
Applied to 8.1 and 8.2 only --- HEAD is getting a cleaner fix, and 8.0 and
before use different coding that seems less vulnerable.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/backend/access/hash:
hashfunc.c (r1.48 -> r1.48.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/hash/hashfunc.c.diff?r1=1.48&r2=1.48.2.1)
pgsql/src/backend/executor:
nodeHash.c (r1.107 -> r1.107.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeHash.c.diff?r1=1.107&r2=1.107.2.1)
pgsql/src/include/access:
hash.h (r1.73.2.1 -> r1.73.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/hash.h.diff?r1=1.73.2.1&r2=1.73.2.2)