log_autoanalyze_min_duration

Definition PG 20 devel manual

Causes analyze action executed by autovacuum to be logged if it ran for at least the specified amount of time. Setting this to zero logs all analyze actions by autovacuum. -1 disables logging analyze actions by autovacuum. If this value is specified without units, it is taken as milliseconds. For example, if you set this to 250ms then all automatic analyzes that run 250ms or longer will be logged. In addition, when this parameter is set to any value other than -1, a message will be logged if an analyze action by autovacuum is skipped due to a conflicting lock or a concurrently dropped relation. The default is 10min. Enabling this parameter can be helpful in tracking analyze activity by autovacuum. This parameter can only be set in the postgresql.conf file or on the server command line; but the setting can be overridden for individual tables by changing table storage parameters.

How it works

PostgreSQL describes log_autoanalyze_min_duration as follows: “Sets the minimum execution time above which analyze actions by autovacuum will be logged.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

Zero logs every automatic ANALYZE, -1 disables these duration messages, and a positive value logs actions meeting the threshold plus relevant skips caused by locks or dropped relations. Per-table storage parameters can override it, independently from log_autovacuum_min_duration for VACUUM actions.

Read it together with log_autovacuum_min_duration, autovacuum, autovacuum_analyze_threshold, autovacuum_analyze_scale_factor. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Operational considerations

Treating the measured boot_val for log_autoanalyze_min_duration as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports sighup context.

Changing this setting in isolation without checking the linked limits, observability, and rollback path.

Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Workload guidance

OLAP: Evaluate the setting with representative long-running and batch work. Measure total runtime, resource use, log volume, and failure behavior across the whole job rather than one isolated operation.

OLTP: Keep the upstream default until a reproducible operational need is demonstrated. Test under representative concurrency and inspect logs, latency, and the related settings before changing cluster-wide policy.

SMALL: Minimize overrides and document rollback. A small system has less room for extra logging, workers, memory, or retained WAL, so validate the change with explicit resource limits.