On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote: > Simon Riggs wrote: > > On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote: > > > Maybe something like this is better: > > > > > > LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed 7199, > > > 2338 remain CPU usage: whatever > > > CONTEXT: Automatic vacuuming of table "database.public.w" > > > > Yours is better. > > > > I've implemented this: > > > > LOG: autovac "public.w" index passes: 1 pages: removed 0, 197 remain > > tuples: removed 7199, 2338 remain CPU usage: whatever > > > > I'm happy if this gets removed later, but I think it will help everybody > > understand how multi-vacuums are working and what the best way to > > specify the controls should be. > > > > Not sure about the CONTEXT bit. I think its verbose, plus I thought that > > was for ERRORs only. I will defer on this point, since I know y'all > > understand that better than I. > > 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. I guess we need to see how this interacts with HOT, as well. Presumably you mean to have both removeds in the same order? > pages: 0 removed, 11226 remain > tuples: 1300683 removed, 1096236 remain -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
