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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
