From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kenneth Marshall <ktm(at)rice(dot)edu> |
Cc: | pgsql-patches(at)postgresql(dot)org, twraney(at)comcast(dot)net, neilc(at)samurai(dot)com |
Subject: | Re: updated hash functions for postgresql v1 |
Date: | 2008-03-17 02:53:02 |
Message-ID: | 21779.1205722382@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Kenneth Marshall <ktm(at)rice(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | ITAGAKI Takahiro | 2008-03-17 03:04:08 | Re: Suppress compiler warnings on mingw |
Previous Message | Bruce Momjian | 2008-03-17 02:21:24 | Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit |