Re: add vacuum starttime columns

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, nickyang <nickyang905(at)gmail(dot)com>
Subject: Re: add vacuum starttime columns
Date: 2024-12-31 16:18:27
Message-ID: CAKAnmm+dREuWpKFp+GXDVqGVFn-zSHB_T6nqHmwkrC3n5yWGXA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 31, 2024 at 2:33 AM wenhui qiu <qiuwenhuifx(at)gmail(dot)com> wrote:

> Of course, to observe the duration of vacuum operations, we can configure
> the log_autovacuum_min_durationparameter, but if there are many tables in
> the database, the vacuum entries in the logs might be quite numerous,
> making it difficult to analyze.
>
> Using log_autovacuum_min_duration really is the best solution here. It is
not very difficult to write a script to pull the information out. Yes, it
can be a lot of lines if there are a lot of tables, but that's part of why
it's a duration and not a toggle - you can ignore the quick-running ones.
Also, the log files give you historical overview that the pg_stat views
simply cannot provide, in addition to the actual details of what was
vacuumed and why. All that is to say that I am not convinced we need to
tweak the system views when we have the information already available in a
better way.

For what it's worth, log_autovacuum_min_duration is one of the few
parameters that I always recommend be turned on at the highest level (i.e.
log it all). The extra log verbosity is well worth it.

Cheers,
Greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rafael Thofehrn Castro 2024-12-31 16:23:03 Re: Proposal: Progressive explain
Previous Message jian he 2024-12-31 16:09:42 Re: using index to speedup add not null constraints to a table