On Sat, Apr 05, 2008 at 05:57:35PM -0400, Tom Lane wrote:
So the proposed changes in hash_any make its hash values different
between big-endian and little-endian machines (at least for string keys;
for keys that are really arrays of int, I think the changes will
unify the behavior). This
Tom Lane [EMAIL PROTECTED] writes:
SELECT dblink_get_connections();
dblink_get_connections
! {dtest1,dtest3,dtest2}
(1 row)
SELECT dblink_is_busy('dtest1');
and right offhand I can't think of a simple way to force those array
elements into a
So the proposed changes in hash_any make its hash values different
between big-endian and little-endian machines (at least for string keys;
for keys that are really arrays of int, I think the changes will
unify the behavior). This means that the hash_seq_search traversal
order for an internal
Tom Lane [EMAIL PROTECTED] 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
Gregory Stark [EMAIL PROTECTED] writes:
Why do we have this hash function anyways? Is hashany faster than a decent
crc32 implementation?
Yes, significantly. Times to hash 32K bytes 10 times on a Xeon EM64T:
hash_crc(32K): 11.388755 s
hash_any_old(32K): 4.401945 s
hash_any(32K): 3.862427 s
