Gregory Stark <stark@enterprisedb.com> writes:
> hashany of a 4-byte value degenerates to pretty much just a call to mix().
> Perhaps we should just expose a hash12() that takes three integers and calls
> mix() on them like hash_any does.
I don't see any use for that, but probably there is a use in hash_uint32(x)
that has the same result as hash_any(&x, sizeof(uint32)).
> And that fix you committed a while back to improve the catcache hash function
> made a huge difference. Now I'm wondering if it shouldn't just be invoking
> hash_any() or mix() too.
No, if the hash values are reasonably random it should be fine as-is.
There should not be any need for multiple layers of hash_any calls.
The big problem with the old version of that code (IMHO) was that it
threw away hash bits, which it doesn't anymore.
What I'm wondering is whether we can't actually simplify the callers, if
we put all the burden on the hash functions to produce all-bits-random
results. In particular hashjoin probably ought to switch to power-of-2
nbuckets to avoid integer divisions ...
regards, tom lane