We just released our second eBook: "The Most Important Events to Monitor in Your Postgres Logs"Download Now

A65: Automatic vacuum of table completed

Category: Autovacuum Events
Urgency: low

Example Postgres Log Output:

LOG: automatic vacuum of table "mydb.public.vac_test": index scans: 1
 pages: 0 removed, 1 remain, 0 skipped due to pins, 0 skipped frozen
 tuples: 3 removed, 6 remain, 0 are dead but not yet removable
 buffer usage: 70 hits, 4 misses, 4 dirtied
 avg read rate: 62.877 MB/s, avg write rate: 62.877 MB/s
 system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec


This log event describes in detail the statistics of a completed autovacuum on a table in the database. Note that this will only be logged when log_autovacuum_min_duration is enabled on your database.

On most systems it is safe to simply turn on autovacuum logs for all durations, which you can do by setting log_autovacuum_min_duration = 0.

Monitoring the log data for these events has benefits compared to other approaches (e.g. sampling pg_stat_progress_vacuum / pg_stat_acivity) since even very fast autovacuum runs will show up in the logs. The downside of course is that you might see a lot of log events, so these are hard to parse through without additional visualization.

One of the useful statistics in this log event, is that you can determine easily how much I/O impact the autovacuum run had, based on the avg read rate and avg write rate. This can be influenced by setting autovacuum_vacuum_cost_delay on the table, or for the database.

Recommended Action:

This log event on its own does not indicate anything bad, after all VACUUM is an integral part of Postgres.

You might want to read up on autovacuum tuning if you encounter certain tables being vacuumed a lot, or vacuum runs taking a lot of time.

Learn More:

Couldn't find what you were looking for or want to talk about something specific?
Start a conversation with us →