On Thu, Jul 18, 2013 at 11:41 AM, Greg Smith <greg@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