On Oct 28, 11:05 am, k(dot)(dot)(dot)(at)rice(dot)edu (Kenneth Marshall) wrote:
> On Sun, Oct 28, 2007 at 05:27:38PM +0000, Simon Riggs wrote:
> > On Sat, 2007-10-27 at 15:15 -0500, Kenneth Marshall wrote:
> > > Its features include a better and faster hash function.
> > Looks very promising. Do you have any performance test results to show
> > it really is faster, when compiled into Postgres? Better probably needs
> > some definition also; in what way are the hash functions better?
> > --
> > Simon Riggs
> > 2ndQuadrant http://www.2ndQuadrant.com
> The new hash function is roughly twice as fast as the old function in
> terms of straight CPU time. It uses the same design as the current
> hash but provides code paths for aligned and unaligned access as well
> as separate mixing functions for different blocks in the hash run
> instead of having one general purpose block. I think the speed will
> not be an obvious win with smaller items, but will be very important
> when hashing larger items (up to 32kb).
> Better in this case means that the new hash mixes more thoroughly
> which results in less collisions and more even bucket distribution.
> There is also a 64-bit varient which is still faster since it can
> take advantage of the 64-bit processor instruction set.
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
I don't make use of 64-bit arithmetic when producing the 64-bit result
in hashlittle2(). Wish I did. The routine internally produces 3 32-
bit results a b c, the returned 64-bit result is roughly c | (b<<32).
In response to
pgsql-patches by date
|Next:||From: Hiroshi Saito||Date: 2007-10-31 16:05:22|
|Subject: ipcclean is excepted by windows.|
|Previous:||From: Tom Lane||Date: 2007-10-30 19:44:44|
|Subject: Re: Obsolete bits in docs for SQL-GRANT |