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