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
