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.
****************************************************************
