From 1f559b7d3aa411e08d2ad46a4bd7d9213945b103 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 1 Jun 2007 15:33:19 +0000 Subject: 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/include/access/hash.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'src/include/access/hash.h') diff --git a/src/include/access/hash.h b/src/include/access/hash.h index 2bd314a8aa..e7f59e2da8 100644 --- a/src/include/access/hash.h +++ b/src/include/access/hash.h @@ -7,7 +7,7 @@ * Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/include/access/hash.h,v 1.81 2007/05/30 20:12:02 tgl Exp $ + * $PostgreSQL: pgsql/src/include/access/hash.h,v 1.82 2007/06/01 15:33:18 tgl Exp $ * * NOTES * modeled after Margo Seltzer's hash implementation for unix. @@ -265,6 +265,7 @@ extern Datum hashname(PG_FUNCTION_ARGS); extern Datum hashtext(PG_FUNCTION_ARGS); extern Datum hashvarlena(PG_FUNCTION_ARGS); extern Datum hash_any(register const unsigned char *k, register int keylen); +extern Datum hash_uint32(uint32 k); /* private routines */ -- cgit v1.2.1