From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: machine-dependent hash_any vs the regression tests |
Date: | 2008-04-05 22:28:07 |
Message-ID: | 87zls8aqdk.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> No doubt that can be worked around, but does anyone wish to argue that
> this whole thing is a bad path to be headed down? We're not going to
> gain a *whole* lot of speedup from the word-wide-hashing change, and
> so maybe this type of headache isn't worth the trouble.
I have to admit to some hesitation about it. But as you point out, regarding
arrays of integers, most of the things being hashed are themselves platform
dependent and have different hashes. So I can't really come up with any good
reason to try to keep hashes consistent across platforms.
I suppose for strings it means you can't use hashtext() in user-space code if
you ever think you might switch database server architectures. You're probably
better off using crc32 (for which we don't provide a function :( ) for user
code anyways.
Why do we have this hash function anyways? Is hashany faster than a decent
crc32 implementation?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2008-04-05 22:43:59 | Re: [HACKERS] Patch queue -> wiki |
Previous Message | Tom Lane | 2008-04-05 21:57:35 | machine-dependent hash_any vs the regression tests |