Re: updated hash functions for postgresql v1 - Mailing list pgsql-patches

From Tom Lane
Subject Re: updated hash functions for postgresql v1
Date
Msg-id 21779.1205722382@sss.pgh.pa.us
Whole thread Raw
In response to updated hash functions for postgresql v1  (Kenneth Marshall <ktm@rice.edu>)
Responses Re: updated hash functions for postgresql v1  (Kenneth Marshall <ktm@rice.edu>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Next
From: ITAGAKI Takahiro
Date:
Subject: Re: Suppress compiler warnings on mingw