Horton

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Shinya Kato <shinya11.kato@gmail.com>
Cc: wenhui qiu <qiuwenhuifx@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Nathan Bossart <nathandbossart@gmail.com>, Michael Banck <mbanck@gmx.net>, pgsql-hackers@postgresql.org
Date: 2025-06-04T18:53:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add log_autoanalyze_min_duration

  2. Generate GUC tables from .dat file

> Approach 2:
> - log_autovacuum_min_duration: Changed behavior, which controls only
> autovacuum logging.
> - log_autoanalyze_min_duration: New parameter, which controls
> autoanalyze logging.

My vote is for this approach. It is probably OK to change the behavior of
log_autovacuum_min_duration, as the new GUC will have the same default
value.

log_autoanalyze_min_duration makes sense, especially since
"autoanalyze" is the term we already use in system views (e.g.,
pg_stat_all_tables.last_autoanalyze). I do not think we need to worry
about consistency with other autovacuum parameters (e.g.,
autovacuum_[vacuum|analyze]_threshold, etc.), because in this case we are
only talking about logging, so we have more flexibility in naming.

Initially, I was not sure if there is a use case in which someone would want
to turn off autovacuum logging but keep autoanalyze logging (or vice versa),
but there may be, and this will be more flexible.

--

Sami Imseih