Re: a verbose option for autovacuum

From: Tommy Li <tommy(at)coffeemeetsbagel(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: a verbose option for autovacuum
Date: 2021-02-02 00:59:35
Message-ID: CAMifU2W2Bk5dE8ev4G9aTpt+ADwE1ufxNdchfxtmp7fFova=pw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Masahiko

> If we set
> it per-table basis, it’s useful when the user already knows which
> tables are likely to take a long time for autovacuum

I would assume that's the default case, most apps I've seen are designed
around a small
number of large tables that take up most of the maintenance effort

> Regarding when to log, we can have autovacuum emit index vacuum log
> after each lazy_vacuum/cleanup_index() end like VACUUM VERBOSE does,
> but I’m not sure how it could work together with
> log_autovacuum_min_duration.

I do like having this rolled into the existing configuration. This might be
an absurd idea, but
what if the autovacuum process accumulates the per-index vacuum information
until that
threshold is reached, and then spits out the logs all at once? And after
the min duration is
passed, it just logs the rest of the index vacuum information as they
occur. That way the
information is more likely to be available to investigate an abnormally
long running vacuum
while it's still happening.

Tommy

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-02-02 01:06:08 Re: Support for NSS as a libpq TLS backend
Previous Message Jacob Champion 2021-02-02 00:55:57 Re: Support for NSS as a libpq TLS backend