Kenneth Marshall <[EMAIL PROTECTED]> writes: > Okay, I will strip the VALGRIND paths. I did not see a real need for them > either.
I have a patch ready to commit (as soon as I fix the regression test issues) that incorporates all the word-wide-ness stuff. All you really need to look at is the question of hash quality. I did confirm that the mixing changes account for a noticeable chunk of the runtime improvement. For instance on a Xeon hash_any_old(32K): 4.386922 s (CVS HEAD) hash_any(32K): 3.853754 s (CVS + word-wide calcs) hashword(32K): 3.041500 s (from patch) hashlittle(32K): 3.092297 s (from patch) hash_any_old(32K unaligned): 4.390311 s hash_any(32K unaligned): 4.380700 s hashlittle(32K unaligned): 3.464802 s hash_any_old(8 bytes): 1.580008 s hash_any(8 bytes): 1.293331 s hashword(8 bytes): 1.137054 s hashlittle(8 bytes): 1.112997 s So adopting the mixing changes would make it faster yet. What we need to be certain of is that this doesn't expose us to poorer hashing. We know that it is critical that all bits of the input affect all bits of the hash fairly uniformly --- otherwise we are subject to very serious performance hits at higher levels in hash join, for instance. The comments in the new code led me to worry that Jenkins had compromised on that property in search of speed. I looked at his website but couldn't find any real discussion of the design principles for the new mixing code ... regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches