Re: Add log_autovacuum_{vacuum|analyze}_min_duration
Shinya Kato <shinya11.kato@gmail.com>
From: Shinya Kato <shinya11.kato@gmail.com>
To: Sami Imseih <samimseih@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-11T04:49:39Z
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 →
-
Add log_autoanalyze_min_duration
- dd3ae378301f 19 (unreleased) landed
-
Generate GUC tables from .dat file
- 63599896545c 19 (unreleased) cited
On Thu, Jun 5, 2025 at 3:53 AM Sami Imseih <samimseih@gmail.com> wrote: > > 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. > Thank you for voting. I also think this approach is reasonable to implement. 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. > +1. > 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. > My concern is less about turning autovacuum and autoanalyze logs on or off individually, and more about the fact that setting a large value for log_autovacuum_min_duration prevents autoanalyze logs from being recorded. -- Best regards, Shinya Kato NTT OSS Center