pgsql: Fix several hash functions that were taking chintzy shortcuts
От | tgl@postgresql.org (Tom Lane) |
---|---|
Тема | pgsql: Fix several hash functions that were taking chintzy shortcuts |
Дата | |
Msg-id | 20070601153319.34C289FB686@postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
Log Message: ----------- 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. Modified Files: -------------- pgsql/src/backend/access/hash: hashfunc.c (r1.51 -> r1.52) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/hash/hashfunc.c.diff?r1=1.51&r2=1.52) pgsql/src/backend/nodes: bitmapset.c (r1.12 -> r1.13) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/nodes/bitmapset.c.diff?r1=1.12&r2=1.13) pgsql/src/backend/utils/hash: hashfn.c (r1.30 -> r1.31) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/hash/hashfn.c.diff?r1=1.30&r2=1.31) pgsql/src/include/access: hash.h (r1.81 -> r1.82) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/hash.h.diff?r1=1.81&r2=1.82) pgsql/src/include/catalog: catversion.h (r1.407 -> r1.408) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h.diff?r1=1.407&r2=1.408)
В списке pgsql-committers по дате отправления: