To: Alvaro Herrera <alvherre@commandprompt.com>
cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-patches@postgresql.org
Subject: Re: log_autovacuum 
In-reply-to: <20070417184550.GC15495@alvh.no-ip.org> 
References: <1173369949.3641.132.camel@silverbirch.site>
	<20070308175330.GW4715@alvh.no-ip.org>
	<1173378696.3641.162.camel@silverbirch.site>
	<20070417180633.GA15495@alvh.no-ip.org>
	<1176834315.3635.414.camel@silverbirch.site>
	<20070417184550.GC15495@alvh.no-ip.org>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Tue, 17 Apr 2007 14:45:50 -0400"
Date: Tue, 17 Apr 2007 14:59:16 -0400
Message-ID: <4686.1176836356@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Simon Riggs wrote:
>> 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.

Sure, log_min_duration_statement.  Applying the same concept to autovac
logging makes sense to me.  In fact, what you've got now is equivalent
to an unconditional log_statement boolean, which is about where we were
three or four releases ago on statement logging.  History suggests that
we'd soon want it to be more flexible than that.  It seems sane to me
to skip the boolean stage and go straight to a threshold parameter.

> Also, why do it by time and not by amount of tuples/pages removed?

One, it's consistent with the way we do thresholded statement logging.
Two, time is a better indicator of effort expended --- consider
vacuuming a very large table that has only a few dead tuples.

We might want to add logging thresholds for pages/tuples later, but
for now I'd vote for just one parameter: a time threshold.

			regards, tom lane