Hi,
On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
> On Tue, Jun 3, 2025 at 4:42 PM Michael Banck <mba...@gmx.net> wrote:
> > On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote:
> > > I am proposing the introduction of two new GUC parameters,
> > > log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing
> > > log_autovacuum_min_duration.
> >
> > How about adding log_autoanalyze_min_duration instead? That would still
> > slightly retcon the log_autovacuum_min_duration meaning/semantics by no
> > longer logging autoanalyze unless the new GUC is set, but at least not
> > rename the GUC and make both shorter while still being comprehensible
> > IMO. Not sure what others think?
>
> 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.
Unless we want to have 4 logging GUCs
(log_{auto,}vacuum_{vacuum,analyze}_min_duration) which I think would
be overkill?
Michael
