On Thu, Jul 18, 2013 at 11:41 AM, Greg Smith <g...@2ndquadrant.com> wrote: > On 7/18/13 11:04 AM, Robert Haas wrote: >> On a system where fsync is sometimes very very slow, that >> might result in the checkpoint overrunning its time budget - but SO >> WHAT? > > Checkpoints provide a boundary on recovery time. That is their only > purpose. You can always do better by postponing them, but you've now > changed the agreement with the user about how long recovery might take. > > And if you don't respect the checkpoint boundary, what you can't do is then > claim better execution performance than something that did. It's always > possible to improvement throughput by postponing I/O. SO WHAT? If that's > OK, you don't need complicated logic to do that. Increase > checkpoint_timeout. The system with checkpoint_timeout at 6 minutes will > always outperform one where it's 5. > > You don't need to introduce a feedback loop--something that has significant > schedule stability implications if it gets out of control--just to spread > I/O out further. I'd like to wander down the road of load-sensitive > feedback for database operations, especially for maintenance work. But if I > build something that works mainly because it shifts the right edge of the > I/O deadline forward, I am not fooled into thinking I did something awesome. > That's cheating, getting better performance mainly by throwing out the > implied contract with the user--the one over their expected recovery time > after a crash. And I'm not excited about complicating the PostgreSQL code > to add a new way to do that, not when checkpoint_timeout is already there > with a direct, simple control on the exact same trade-off.
That's not the same trade-off. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
