3

Postgres recommends using the autovacuum to remove the dead tuples. But does running the autovacuum end up making other queries to the same table slow? Does it add locks (row or table level) which impact performance? Is there a significant load on CPU or does it consume lot of memory.

This will help us decide if we should turn on autovacuum for one of our tables which has very high amount of writes and deletes or if we should rather run a manual vacuum regularly during off peak hours.

Aroj
  • 33
  • 1
  • 1
  • 3

1 Answers1

7

It's memory usage is constrained by autovacuum_work_mem or maintenance_work_mem. It's IO consumption is constrained by autovacuum_vacuum_cost_delay and friends, and the defaults for these lead to quite low IO demand. The CPU usage is not directly constrained, but is indirectly constrained by the IO consumption throttle, and with the default setting will usually be close to negligible.

Autovacuum does take a lock on the table, but it is a weak lock which does not interfere with normal operations (SELECT, UPDATE, DELETE) but will interfere with things like adding indexes, or truncating the table. Autovacuum will usually cancel itself and surrender the lock when it detects it is blocking something, but it won't do that if it is in "to prevent wraparound" mode.

Autovacuum is on by default. You should not turn it off. Running manual vacuums during off-peak hours is fine, but leave autovacuum on as a back-stop to catch whatever your manual vacuum misses.

Phil Frost
  • 103
  • 2
jjanes
  • 39,726
  • 3
  • 37
  • 48
  • Is the "Autovacuum will usually cancel itself and surrender the lock when it detects it is blocking something" behavior documented anywhere? – Phil Frost Jun 11 '21 at 03:04
  • 2
    @PhilFrost Yes, but the docs call it 'interrupt', not 'cancel'. See here https://www.postgresql.org/docs/13/routine-vacuuming.html#AUTOVACUUM – jjanes Jun 11 '21 at 15:07