Re: Hash joins vs small-integer join values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, "Joseph Shraibman" <jks(at)selectacast(dot)net>
Subject: Re: Hash joins vs small-integer join values
Date: 2007-06-01 14:12:34
Message-ID: 25013.1180707154@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2007-06-01 14:17:16 Re: Concurrent psql patch
Previous Message Tom Lane 2007-06-01 13:39:15 Re: Feature freeze status report