> 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. May I suggest we keep its current behavior, which is to control
logging for both autoanalyze and autovacuum, and instead introduce only one
new GUC, log_autovacuum_analyze_min_duration, which defaults to -1? For
workloads that require different logging for autoanalyze, this new setting
can be enabled.
--
Sami Imseih
Amazon Web Services (AWS)
