Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group