On Tue, 2007-04-17 at 14:45 -0400, Alvaro Herrera wrote: > 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.
log_temp_files works a bit like that, as does log_min_duration_statement perhaps log_min_duration_vacuum? that would be easier to understand > 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? ...because you only want to know about slow vacuums. Time is a more natural unit than tuples removed. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend