Fix several hash functions that were taking chintzy shortcuts instead of
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 1 Jun 2007 15:33:19 +0000 (15:33 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 1 Jun 2007 15:33:19 +0000 (15:33 +0000)
commit1f559b7d3aa411e08d2ad46a4bd7d9213945b103
treedf4325affc882914a2dd6c6e8a8160ffc223a057
parent397d00af8f0526c78eef5999e85ce6a3d5e9e36f
Fix several hash functions that were taking chintzy shortcuts instead of
delivering a well-randomized hash value.  I got religion on this after
observing that performance of multi-batch hash join degrades terribly if the
higher-order bits of hash values aren't random, as indeed was true for say
hashes of small integer values.  It's now expected and documented that hash
functions should use hash_any or some comparable method to ensure that all
bits of their output are about equally random.

initdb forced because this change invalidates existing hash indexes.  For the
same reason, this isn't back-patchable; the hash join performance problem
will get a band-aid fix in the back branches.
src/backend/access/hash/hashfunc.c
src/backend/nodes/bitmapset.c
src/backend/utils/hash/hashfn.c
src/include/access/hash.h
src/include/catalog/catversion.h