Jim Nasby <jim.na...@bluetreble.com> writes: > On 12/24/14, 10:58 AM, Tom Lane wrote: >> Andres Freund <and...@2ndquadrant.com> writes: >>> FWIW, I don't believe these results for one second. It's quite plausible >>> that there's a noticeable performance benefit, but a factor of three is >>> completely unrealistic... Could you please recheck?
>> A possible theory is that the hash change moved some locks into >> different partitions causing a large reduction in contention, >> but even then 3X seems unlikely. And of course if that was >> the mechanism, the result is still pure luck; other examples >> might get worse by the same amount. > I must have screwed something up, because if anything I see a small loss for > XXH now (but my laptop isn't consistent enough to be sure). > This surprises me given that SMHasher shows XXH to be 50% faster than > Spooky for 20 byte keys. The speed of the hash calculation itself is unlikely to move the needle as much as 1% either direction, because I've seldom seen any profile in which hash_any accounted for more than a percent or so of total runtime. What is far more likely to be causing visible performance changes is downstream effects, ie changes in the distribution of entries across hash buckets, causing changes in bucket list search times and/or changes in contention (for shared memory tables that are locked on a hash-partition basis). But even then it's hard to credit 3X. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers