Re: Add log_autovacuum_{vacuum|analyze}_min_duration

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>
To: Michael Banck <mbanck@gmx.net>
Cc: Shinya Kato <shinya11.kato@gmail.com>, pgsql-hackers@postgresql.org
Date: 2025-06-03T18:47:11Z
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

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 (e.g., to only logging vacuums).  Maybe that's acceptable if we
buy the assertion that autoanalyze is typically much faster than autovacuum
(and so autoanalyzes weren't getting logged, anyway).

-- 
nathan