On 3/19/13 8:17 PM, Simon Riggs wrote:
> We know that will work, has reasonable distribution characteristics
> and might even speed things up rather than have two versions of CRC in
> the CPU cache.
That sounds reasonable to me. All of these CRC options have space/time
trade-offs via how large the lookup tables they use are. And if those
are already sitting in the CPU data cache via their use in the WAL
writes, using them for this purpose too could give them an advantage
that's not obvious in a synthetic test. I'm curious how that plays out
when multiple cores are involved too.
It would be hilarious if optimizing the CRC calculation makes WAL-heavy
workloads with checksums still net faster in the next release. Makes me
wonder how much of the full-page write overhead is being gobbled up by
CRC time already, on systems with a good sized write cache.
> I'd rather get this committed with a safe option and then y'all can
> discuss the fine merits of each algorithm at leisure.
Yes, that's what we're already doing--it just looks like work :)
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
