Learn the vocabulary of the background process that reclaims space from updated and deleted rows.
0 / 5 completed
1 / 5
At standup, a dev mentions a background process that reclaims space from rows an update or delete left behind as dead tuples, rather than a person manually running cleanup. What is this process called?
Autovacuum is the background process that reclaims space left behind as dead tuples by an update or a delete, since Postgres's MVCC design keeps the old row version around until it's no longer needed by any transaction. Read replication copies data for availability and scaling reads, which is an entirely different concern from reclaiming dead-tuple space. This automated reclamation is what keeps a table's physical size from growing unbounded as rows are updated and deleted over time.
2 / 5
During a design review, the team wants a high-churn table's autovacuum thresholds tuned to run more aggressively than the cluster-wide default, since that table accumulates dead tuples far faster than average. Which capability supports this?
Per-table autovacuum settings let the team override the cluster-wide default thresholds for one specific high-churn table, making autovacuum trigger more aggressively where dead tuples accumulate far faster than average. Relying only on the cluster-wide default risks that specific table falling behind and bloating even while every other table stays healthy. This per-table tuning is a standard technique once a specific table's write pattern is known to diverge from the norm.
3 / 5
In a code review, a dev notices a long-running analytical transaction is holding back the oldest transaction ID the database needs to track, preventing autovacuum from reclaiming dead tuples that transaction could theoretically still see. What does this represent?
A long-running transaction starving autovacuum is exactly what happens when that transaction holds back the oldest transaction ID the database must still consider visible, preventing autovacuum from reclaiming any dead tuple that transaction could theoretically still read. A read replica is an unrelated concept about serving read traffic. This starvation is a well-known cause of unexpected table bloat that has nothing to do with autovacuum's own settings being misconfigured.
4 / 5
An incident report shows a table's disk usage grew far beyond its actual row count because autovacuum couldn't keep up with the churn from a batch job, and disk space eventually ran critically low. What practice would prevent this?
Tuning autovacuum to run more aggressively on the affected table, combined with checking for a long-running transaction that might be starving it, addresses the two most common reasons a table's dead tuples pile up faster than they're reclaimed. Leaving the defaults unchanged with no investigation is exactly what let disk usage grow critically in this incident. This combination of tuning and root-cause investigation is the standard response once table bloat has already become a production concern.
5 / 5
During a PR review, a teammate asks why the team explicitly tunes autovacuum thresholds for a specific high-churn table instead of trusting the database's default settings to handle every table equally well. What is the reasoning?
The default thresholds are tuned as a general-purpose compromise that works reasonably across every table in a cluster, which means a table with unusually high update or delete churn can still bloat faster than autovacuum reclaims it under those same defaults. Per-table tuning lets that specific table's autovacuum triggers fire proportionally to its own actual churn rate. The tradeoff is the added maintenance burden of identifying which tables actually need a custom threshold instead of leaving every table on the default.