On 26 Srpen 2011, 0:39, Tomas Vondra wrote: > On 26 Srpen 2011, 0:18, Josh Berkus wrote: >> Tomas, >> >>> I'd like to propose a small patch that allows better checkpoint >>> progress >>> monitoring. The patch is quite simple - it adds a new integer GUC >>> "checkpoint_update_limit" and every time checkpoint writes this number >>> of >>> buffers, it does two things: >> >> I'd rather not have a new GUC if we can avoid it. What about just >> making this some reasonable value (like 1000 buffers) if log_checkpoints >> = on? > > I was thinking about that too, but I think no value can fit all cases > because the systems may have very different I/O subsystems. > > With one 7.2k drive I usually get about 25MB/s on average, with big arrays > / good controllers / fast drives you can write much faster. So either the > value will be too low (and the log will be infested with those messages) > or too high (so it won't be updated very often).
Hmmm, maybe we could use time instead of number of buffers? Something like "every 5 seconds, log the checkpoint progress" instead of "every time 1000 buffers is written ..." That should work on systems regardless of I/O performance. But although using time instead of number of buffers seems like a good idea, I don't think it eliminates the need for a new GUC. (a) Even with time limit, I find it useful to be able to set the limits differently. (b) In some cases it may be useful to enable just basic (current behaviour) checkpoint logging using log_checkpoints, so using it for this new patch may not be a good idea. Although this could be fixed by allowing three values no/basic/detailed instead of just true/false. Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
