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.
-- 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
