Re: log_autovacuum
От | Bill Moran |
---|---|
Тема | Re: log_autovacuum |
Дата | |
Msg-id | 20070417151004.f59498b0.wmoran@collaborativefusion.com обсуждение исходный текст |
Ответ на | Re: log_autovacuum (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: log_autovacuum
|
Список | pgsql-patches |
In response to Alvaro Herrera <alvherre@commandprompt.com>: > Simon Riggs wrote: > > On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote: > > > > I've tinkered with this patch a bit. Sample output: > > > > > > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0 > > > pages: removed 0, 11226 remain > > > tuples: 1300683 removed, 1096236 remain > > > system usage: CPU 0.29s/0.38u sec elapsed 2.56 sec > > > > > > Please comment. > > > > Well, 'tis great except when you have very very frequent autovacuums. > > That was why I wanted it in 1 log line. > > > > Perhaps we need this as an integer, so we can log all vacuums that last > > for longer in seconds than the setting, 0 logs all. That would > > significantly reduce the volume if we set it to 5, say. That way you > > would get your readability and I would get my reasonable size logs. > > It kinda smells funny to have a setting like that. Do we have a > precedent? If other people is OK with it, I'll do that. > > Would it work to add a separate GUC var to control the minimum autovac > time? Also, why do it by time and not by amount of tuples/pages > removed? When I submitted the log_temp_files stuff, there was considerable discussion on the topic of how the GUC vars should be done. IIRC, the eventual decision was to have a single GUC var, where -1 equated to off, 0 equated to log all, and numbers higher than 0 were a size limit on when things get logged. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****************************************************************
В списке pgsql-patches по дате отправления: