Hvad er VACUUM og hvorfor er det vigtigt?

Question

Accepted Answer

**`VACUUM`** er PostgreSQL's vedligeholdelses proces, der genvinder lagerplads fra **dead tuples** (forældede rækkeversioner efterladt af MVCC) og opdaterer statistik. Fordi Postgres's MVCC skaber døde rækker ved hver UPDATE/DELETE, er VACUUM afgørende for at forhindre **bloat** og holde databasen sund. **Autovacuum** automatiserer det.

## Hvorfor dead tuples eksisterer (MVCC-forbindelsen)

```text
MVCC: an UPDATE/DELETE doesn't overwrite a row — it marks the old version obsolete
(a "dead tuple") and may create a new one. Dead tuples accumulate over time.
→ Without cleanup, dead tuples cause BLOAT: wasted disk space, slower scans
  (more data to read), degraded performance.
VACUUM reclaims this dead space → keeps tables compact and queries fast.
```

## Hvad VACUUM gør

```sql
VACUUM users;                  -- reclaim dead-tuple space (reusable, but doesn't shrink the file)
VACUUM FULL users;             -- rewrites the table → reclaims space to the OS, but LOCKS
                               -- the table (avoid in production / use sparingly)
VACUUM ANALYZE users;          -- vacuum + update statistics (for the query planner)
ANALYZE users;                 -- update statistics only (helps the planner choose good plans)
```

```text
VACUUM      → marks dead-tuple space reusable (no exclusive lock — normal maintenance)
VACUUM FULL → fully reclaims space to the OS but rewrites + LOCKS the table (heavy)
ANALYZE     → updates table statistics so the planner makes good decisions
```

## Autovacuum — automatisk vedligeholdelse

```text
AUTOVACUUM runs automatically in the background, vacuuming/analyzing tables when
enough rows have changed → handles routine maintenance without manual intervention.
→ Usually leave it ON. Tune its settings for high-write tables that need more
  frequent vacuuming (or it falls behind → bloat builds up).
```

## Symptomer på vacuum-problemer

```text
✗ Table/index BLOAT (much larger than the actual data) → slow queries, wasted space
✗ Outdated statistics → the planner picks bad query plans
✗ Transaction ID wraparound risk (if vacuum is severely neglected — a serious issue)
→ Monitor with pg_stat_user_tables (dead tuple counts, last vacuum time)
```

## Hvorfor det betyder noget

At forstå VACUUM er vigtigt for at **drive PostgreSQL** korrekt, fordi det er en direkte konsekvens af Postgres's MVCC-arkitektur og er afgørende for databasens sundhed — hvis man overser det, forårsager det rigtige, alvorlige ydelses- og driftsproblemer.

Den fundamentale forbindelse er, at **MVCC skaber dead tuples** (forældede rækkeversioner) ved hver UPDATE og DELETE, og disse akkumuleres som **bloat** (spilder plads, langsommere skanninger, forringet ydeevne), medmindre de ryddes op — VACUUM er denne oprydning, der genvinder dead-tuple-plads og holder tabeller kompakte og forespørgsler hurtige.

At forstå varianterne — almindelig `VACUUM` (genvinder plads til genbrug, normal vedligeholdelse, ingen tungt locking), `VACUUM FULL` (genvinder fuldt plads til OS'et men omskriver og låser tabellen, så den bruges sparsommeligt), og `ANALYZE` (opdaterer statistik, så query planlageren træffer gode beslutninger) — er vigtigt for vedligeholdelse.

At vide om **autovacuum** (den automatiske baggrundsproces, der håndterer rutinemæssig vacuuming, som du normalt lader være tændt men kan være nødt til at *tuning* for high-write-tabeller, så den ikke halter bagud) er vigtig driftsviden.

At genkende **symptomerne på vacuum-problemer** (tabel/indeks bloat, forældet statistik, der forårsager dårlige query-planer, og den alvorlige risiko for transaction ID wraparound, hvis vacuum alvorligt overses) og hvordan man overvåger dem, er vigtigt for at holde produktionsdatabaser sunde.

Fordi VACUUM er en PostgreSQL-specifik driftsnødvendighed (direkte stammer fra MVCC), og fordi man ved at overse det forårsager bloat, langsomme forespørgsler, dårlige planer og endda kritiske wraparound-problemer, er det vigtigt senior-level-viden at forstå VACUUM — hvorfor det er nødvendigt (MVCC dead tuples), hvad varianterne gør, autovacuum, og symptomerne på problemer — for at drive PostgreSQL pålideligt i produktion, en hyppigt relevant vedligeholdelses-concern, der adskiller dem, der kan drive Postgres i produktion, fra dem, der rammer undgåelig ydelses-forringelse.