Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 12/24/14, 10:58 AM, Tom Lane wrote:
>> Andres Freund <andres(at)2ndquadrant(dot)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