"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
> element
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 m
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.86242
"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 wort
