On Fri, Aug 30, 2013 at 3:02 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> I am not sure "hot cache large buffer performance" is really the
> interesting case. Most of the XLogInsert()s are pretty small in the
> common workloads. I vaguely recall trying 8 and getting worse
> performance on many workloads, but that might have been a problem of my
> implementation.
Slice-by-8 doesn't have any overhead for small buffers besides the
lookup tables, so it most likely the cache misses that were the issue.
Murmur3, CityHash and SpookyHash don't have any lookup tables and are
excellent with small keys. Especially CityHash, 64 byte hash is quoted
at 9ns.
> The reason I'd like to go for a faster CRC32 implementation as a first
> step is that it's easy. Easy to verify, easy to analyze, easy to
> backout. I personally don't have enough interest/time in the 9.4 cycle
> to purse conversion to a different algorithm (I find the idea of using
> different ones on 32/64bit pretty bad), but I obviously won't stop
> somebody else ;)
I might give it a shot later this cycle as I have familiarized my self
with the problem domain anyway. I understand the appeal of staying
with what we have, but this would cap the speedup at 4x and has large
caveats with the extra lookup tables. A 28x speedup might be worth the
extra effort.
Regards,
Ants Aasma