On Mon, 29 Sep 2008, Simon Riggs wrote:
I'm surprised that checkpoint smoothing moves slowly even when it has so little to do. ISTM checkpoint completion target should set its write rate according to the thought that if shared_buffers were all dirty it would write them out in checkpoint_timeout * checkpoint_completion_target seconds. However, what it does is write them *all* out in that time, no matter how many dirty blocks there are. If there is just a few blocks to write, we take the *same* time to write them as if it were all dirty.
The checkpoint smoothing code that made it into 8.3 missed a couple of nice to have features that just didn't make the schedule cut-off. Enforcing a minimum rate was one, another was smoothing fsync calls.
Back when we were talking about the patch to sort writes at checkpoint time, someone (I think you actually) commented that it might be worthwile to create some sort of hook for making behavior of checkpoint-time dirty buffer processing easy to change with a custom strategy. The sorted behavior would then be the first such strategy available. Another one I was thinking of was something that specified min+max write writes, which would make this problem go away--might even auto-tune checkpoint_segments or replace it altogether with an implementation based on those inputs.
-- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
