On Sun, Mar 16, 2008 at 10:53:02PM -0400, Tom Lane wrote: > Kenneth Marshall <[EMAIL PROTECTED]> writes: > > Dear PostgreSQL Developers, > > This patch is a "diff -c" against the hashfunc.c from postgresql-8.3beta1. > > It's pretty obvious that this patch hasn't even been tested on a > big-endian machine: > > > + #ifndef WORS_BIGENDIAN > > However, why do we need two code paths anyway? I don't think there's > any requirement for the hash values to come out the same on little- > and big-endian machines. In common cases the byte-array data being > presented to the hash function would be different to start with, so > you could hardly expect identical hash results even if you had separate > code paths. > > I don't find anything very compelling about 64-bit hashing, either. > We couldn't move to that without breaking API for hash functions > of user-defined types. Given all the other problems with hash > indexes, the issue of whether it's useful to have more than 2^32 > hash buckets seems very far off indeed. > > regards, tom lane >
Yes, there is that typo but it has, in fact, been tested on big and little-endian machines. Since, it was a simple update to replace the current hash function used by PostgreSQL with the new version from Bob Jenkins. The test for the endian-ness of the system allows for the code paths to be optimized for the particular CPU. The 64-bit hashing was included for use during my work on on the hash index. Part of that will entail testing the performance of various permutations of previously submitted suggestions. Regards, Ken Marshall -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches