On Thu, Feb 4, 2016 at 4:42 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-02-03 09:57:00 -0500, Robert Haas wrote: >> On Mon, Feb 1, 2016 at 7:43 PM, Andres Freund <and...@anarazel.de> wrote: >> > I wonder if this essentially point at checkpoint_timeout being wrongly >> > defined: Currently it means we'll try to finish a checkpoint >> > (1-checkpoint_completion_target) * timeout before the next one - but >> > perhaps it should instead be that we start checkpoint_timeout * _target >> > before the next timeout? Afaics that'd work more graceful in the face of >> > restarts and forced checkpoints. >> >> There's a certain appeal to that, but at the same time it seems pretty >> wonky. Right now, you can say that a checkpoint is triggered when the >> amount of WAL reaches X or the amount of time reaches Y, but with the >> alternative definition it's a bit harder to explain what's going on >> there. > > Hm, but can you, really? We *start* a checkpoint every > checkpoint_timeout, but we only finish it after > checkpoint_completion_target * timeout, or cct * segments. I find it > pretty hard to explain that we have a gap of checkpoint_timeout, where > nothing happens, after an immediate/manual checkpoint. > > Defining it as: We try to *finish* a checkpoint every checkpoint_timeout > or checkpoint_segments/(max_wal_size/~3) actually seems simpler to > me. Then we just need to add that we start a checkpoint > checkpoint_completion_target before either of the above are reached.
Hmm, I could go for that. -- 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