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 greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
