On Oct 28, 11:05 am, [EMAIL PROTECTED] (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.
> Ken
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>                http://www.postgresql.org/about/donate

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).

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to