Re: PATCH: regular logging of checkpoint progress
От | Tomas Vondra |
---|---|
Тема | Re: PATCH: regular logging of checkpoint progress |
Дата | |
Msg-id | eb41e89c2d6e687ebf9eb4c4c78057f2.squirrel@sq.gransy.com обсуждение исходный текст |
Ответ на | Re: PATCH: regular logging of checkpoint progress ("Tomas Vondra" <tv@fuzzy.cz>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: