Re: log_autovacuum

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: log_autovacuum
Дата
Msg-id 4686.1176836356@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: log_autovacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: log_autovacuum
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)