Thread: Re: Add log_autovacuum_{vacuum|analyze}_min_duration
Hi,
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?
Michael
> 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)
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
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
> Approach 2:
> - log_autovacuum_min_duration: Changed behavior, which controls only
> autovacuum logging.
> - log_autoanalyze_min_duration: New parameter, which controls
> autoanalyze logging.
> - 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.
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.
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.
--
Sami Imseih