Re: Enabling Checksums
Greg Smith <greg@2ndquadrant.com>
From: Greg Smith <greg@2ndQuadrant.com>
To: Ants Aasma <ants@cybertec.at>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Simon Riggs <simon@2ndquadrant.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-03-19T22:52:19Z
Lists: pgsql-hackers
On 3/19/13 6:08 PM, Ants Aasma wrote: > My main worry is that there is a reasonably > large population of users out there that don't have that acceleration > capability and will have to settle for performance overhead 4x worse > than what you currently measured for a shared buffer swapping > workload. That would be very bad. I want to keep hammering on this part of the implementation. If the only style of checksum that's computationally feasible is the Fletcher one that's already been done--if that approach is basically the most expensive one that's practical to use--I'd still consider that a major win over doing nothing. While being a lazy researcher today instead of writing code, I discovered that the PNG file format includes a CRC-32 on its data chunks, and to support that there's a CRC32 function inside of zlib: http://www.zlib.net/zlib_tech.html Is there anywhere that compiles a PostgreSQL --without-zlib that matters? The UI looks like this: ZEXTERN uLong ZEXPORT crc32 OF((uLong crc, const Bytef *buf, uInt len)); And they've already put some work into optimizing its table-driven implementation. Seems possible to punt the whole problem of how to do this efficiently toward the zlib developers, let them drop into assembly to get the best possible Intel acceleration etc. one day. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com