Why should you care?

PostgresVerse orders after flash sale hits n_dead_tup millions — default autovacuum too slow for churn rate.

See it live — copy this example

Run in pgAdmin or psql.

ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.02,
  autovacuum_analyze_scale_factor = 0.01,
  autovacuum_vacuum_cost_delay = 2
);

SELECT relname, last_autovacuum, last_autoanalyze, n_dead_tup
FROM pg_stat_user_tables
WHERE relname = 'orders';

What happened?

• Lower scale_factor triggers vacuum at 2% dead tuples not 20%.
• Reduced cost_delay makes vacuum more aggressive on this table only.
• Monitor last_autovacuum after change.

Practice next

1. Check n_dead_tup and last_autovacuum on hot tables.
2. Apply per-table settings on orders.
3. Watch pg_stat_progress_vacuum during peak churn test.
4. Increase autovacuum_max_workers temporarily during sale prep.
5. Log autovacuum duration via log_autovacuum_min_duration = 0 in lab.

Remember

Tune hot tables individually. Analyze scale factor separate from vacuum. Monitor wraparound age pg_database datfrozenxid.

PostgresVerse sale prep

DBA lowers orders scale_factor week before sale; dead tuples stay under 5%.

Outcome: No autovacuum emergency mid-event; index-only scans stay valid.