Horton

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

wenhui qiu <qiuwenhuifx@gmail.com>

View thread
From: wenhui qiu <qiuwenhuifx@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Sami Imseih <samimseih@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, Michael Banck <mbanck@gmx.net>, Shinya Kato <shinya11.kato@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-06-04T01:30:25Z
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

HI
I vote log_autovacuum_{vacuum|analyze}_min_duration. Then don't remove
log_autovacuum_min_duration so easily!

On Wed, Jun 4, 2025 at 7:16 AM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:

>
>
> On 2025/06/04 4:32, Sami Imseih wrote:
> >> On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote:
> >>> On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
> >>>> I surely think adding log_autoanalyze_min_duration is simpler and
> >>>> shorter, but the reason I chose this GUC name is for consistency with
> >>>> other autovacuum parameters. Existing autovacuum parameters that have
> >>>> separate settings for vacuum and analyze operations follow the pattern
> >>>> autovacuum_{vacuum|analyze}_*.
> >>>>
> https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUM
> >>>
> >>> Right, but the GUCs that directly affect either vacuum or autovacuum
> >>> behaviour need the qualification (and then vacuum/analyze on top of
> it).
> >>> I think we have less constraints with the logging GUC and do not need
> to
> >>> mirror the behaviorial GUCs at all costs. But again, that is just my
> two
> >>> cents.
> >>
> >> I lean towards log_autovacuum_{vacuum|analyze}_min_duration.  If
> >> log_autovacuum_min_duration didn't exist, that's probably the naming
> scheme
> >> we'd go with.  However, I'm not sure we can get away with renaming
> >> log_autovacuum_min_duration.  Presumably we'd need to at least keep it
> >> around as a backward-compatibility GUC, and its behavior would probably
> >> change, too
> >
> > I think deprecating a GUC like log_autovacuum_min_duration would be quite
> > difficult.
>
> Also deprecating the log_autovacuum_min_duration reloption might be tricky.
> If we remove support for it in v19, how should pg_dump handle tables with
> this option set from older versions? Should it translate it into both
> log_autovacuum_vacuum_min_duration and log_autovacuum_analyze_min_duration
> during dump? Would pg_upgrade run into the same issue?
>
> Regards,
>
> --
> Fujii Masao
> NTT DATA Japan Corporation
>
>
>
>