Re: log_autovacuum - Mailing list pgsql-patches

From Tom Lane
Subject Re: log_autovacuum
Date
Msg-id 4686.1176836356@sss.pgh.pa.us
Whole thread Raw
In response to Re: log_autovacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: log_autovacuum
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)