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). And it depends on the number of shared buffers too. I thought it could be something like 5% of shared buffers but it really does not solve the issues. So I think there should be a new GUC. OTOH, it's probably a good idea to log this only when the log_checkpoints is enabled as those who tune checkpoints will enable log_checkpoints in the first case. Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
