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:

Reply via email to