On Sun, Mar 16, 2008 at 10:53:02PM -0400, Tom Lane wrote:
> Kenneth Marshall <ktm@rice.edu> 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
