Re: Enabling Checksums

Greg Stark <stark@mit.edu>

From: Greg Stark <stark@mit.edu>
To: Bruce Momjian <bruce@momjian.us>
Cc: Greg Smith <greg@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>, Ants Aasma <ants@cybertec.at>, Heikki Linnakangas <hlinnakangas@vmware.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-03-20T12:13:51Z
Lists: pgsql-hackers
On Mon, Mar 18, 2013 at 5:52 PM, Bruce Momjian <bruce@momjian.us> wrote:
> With a potential 10-20% overhead, I am unclear who would enable this at
> initdb time.

For what it's worth I think cpu overhead of the checksum is totally a
red herring.. Of course there's no reason not to optimize it to be as
fast as possible but if we say there's a 10% cpu overhead due to
calculating the checksum users will think that's perfectly reasonable
trade-off  and have no trouble looking at their cpu utilization and
deciding whether they have that overhead to spare. They can always buy
machines with more cores anyways.

Added I/O overhead, especially fsync latency is the performance impact
that I think we should be focusing on. Uses will be totally taken by
surprise to hear that checksums require I/O. And fsync latency to the
xlog is very very difficult to reduce. You can buy more hard drives
until the cows come home and the fsync latency will hardly change.
-- 
greg