log_autovacuum_min_duration
Read PG 18 manual ↗Causes each action executed by autovacuum to be logged if it ran for at least the specified amount of time.
- Type
- integer
- Context
- sighup
- Measured default
- 10 min
- Unit
- ms
- Metadata snapshot
- 18
Definition PG 18 manual
Causes each action executed by autovacuum to be logged if it ran for at least the specified amount of time. Setting this to zero logs all autovacuum actions. -1 disables logging autovacuum actions. If this value is specified without units, it is taken as milliseconds. For example, if you set this to 250ms then all automatic vacuums and 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 autovacuum action is skipped due to a conflicting lock or a concurrently dropped relation. The default is 10min. Enabling this parameter can be helpful in tracking autovacuum activity. 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.
Measured default history
| Version interval | Default |
|---|---|
| 9.0 – 14 | -1 ms |
| 15 – 19 | 10 min |
Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗
How it works
log_autovacuum_min_duration sets the minimum execution time above which autovacuum actions will be logged. -1 disables logging autovacuum actions. 0 means log all autovacuum actions. Each qualifying automatic VACUUM or ANALYZE emits timing and work details; -1 disables these completion records and zero records every action.
log_autovacuum_min_duration is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.
It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.
Operational considerations
Editing log_autovacuum_min_duration without reloading configuration and verifying the effective value and subsequent behavior.
Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.
Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.
Changing log_autovacuum_min_duration globally without a rollback plan and a client or operational compatibility test.
Workload guidance
OLAP: Analytical jobs can justify richer log_autovacuum_min_duration telemetry, but account for long statements, large bind values, and bursty completion patterns in the log pipeline.
OLTP: Tune log_autovacuum_min_duration against an explicit observability question and a measured log-volume budget. Prefer selective thresholds, sampling, or role-level overrides over indiscriminate capture.
SMALL: Keep log_autovacuum_min_duration useful but bounded: verify disk, collector, retention, and redaction capacity before increasing detail or frequency.
Version history 7
- PG 18 → 19changed
- PG 17 → 18changed
- PG 14 → 15changed
- PG 11 → 12changed
- PG 10 → 11changed
- PG 9.4 → 9.5changed
- PG 9.0 → 9.1changed
Related entries
Further reading
Definition snapshot: english-manuals:66ada8bc389e7510657296ab48c… · English manual source