Kenneth Marshall <ktm@rice.edu> 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