Autovacuum scale factor raised so high the table bloats before it runs
Note — this works and blocks nothing, but a performance regression is likely.
What it catches
autovacuum_vacuum_scale_factor is the fraction of the table that must change before autovacuum touches it; the server default is 0.2. At 0.5 or above, a table has to accumulate dead rows equal to half its size before cleanup starts — bloat, slower scans, and index bloat pile up in the meantime, and the eventual vacuum is a long one. The same holds for the analyze scale factor and stale planner statistics. Escalates when the live schema shows the table is large or hot.
Fires on
ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.8);Do this instead
Large, busy tables want a LOWER scale factor than the default, not a higher one: small, frequent vacuums are cheap. If the intent was to stop autovacuum interfering with a batch job, use a cost delay or schedule the job — or RESET the option afterwards.
SET lock_timeout = '5s';
ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.05, autovacuum_analyze_scale_factor = 0.02); This rule runs in the hosted service on Startup and above — add --remote with a team token, or use the GitHub Action: npx bolvrk check migration.sql