Co je VACUUM a proč je důležitý?

Question

Accepted Answer

**`VACUUM`** je PostgreSQL maintenance proces, který obnovuje úložiště z **dead tuples** (zastaralé verze řádků zanechané MVCC) a aktualizuje statistiky. Protože PostgreSQL MVCC vytváří dead rows při každém UPDATE/DELETE, VACUUM je nezbytný, aby se zabránilo **bloatu** a databáze zůstala zdravá. **Autovacuum** jej automatizuje.

## Proč dead tuples existují (vazba na MVCC)

```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.
```

## Co VACUUM dělá

```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 — automatická údržba

```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).
```

## Příznaky problémů s vakuováním

```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)
```

## Proč je to důležité

Rozvumění VACUUM je důležité pro **správný provoz PostgreSQL**, protože je to přímý důsledek PostgreSQL MVCC architektury a je nezbytné pro zdraví databáze — zanedbání ho způsobuje skutečné, vážné problémy s výkonem a operacemi.

Základní vazba je, že **MVCC vytváří dead tuples** (zastaralé verze řádků) při každém UPDATE a DELETE, a ty se akumulují jako **bloat** (zbytečný prostor, pomalejší skeny, degradovaný výkon), pokud nejsou vyčištěny — VACUUM je to čištění, které obnovuje prostor dead-tuples a udržuje tabulky kompaktní a dotazy rychlé.

Rozvumění variant — běžný `VACUUM` (obnovuje prostor pro opětovné použití, normální údržba, bez těžkého uzamykání), `VACUUM FULL` (plně obnovuje prostor do OS, ale přepisuje a zamyká tabulku, takže se používá jen zřídka), a `ANALYZE` (aktualizuje statistiky, aby query planner dělal dobrá rozhodnutí) — je důležité pro údržbu.

Věděti o **autovacuumu** (automatický proces na pozadí, který řídí rutinní vakuování, který obvykle necháte zapnutý, ale možná budete muset *vyladit* pro tabulky s vysokou zápisy, aby nestihly zaostávat) je klíčová operační znalost.

Rozeznání **příznaků problémů s vakuováním** (bloat tabulek/indexů, zastaralé statistiky způsobující špatné query plány, a vážné riziko wraparound transaction ID, pokud je vakuování vážně zanedbáno) a jak je sledovat, je důležité pro udržování production databází v pořádku.

Protože VACUUM je PostgreSQL-specifická operační nutnost (vycházející přímo z MVCC), a protože jeho zanedbání způsobuje bloat, pomalé dotazy, špatné plány a dokonce kritické wraparound problémy, rozvumění VACUUM — proč je potřeba (MVCC dead tuples), co jednotlivé varianty dělají, autovacuum, a příznaky problémů — je důležitá znalost na úrovni seniora pro spolehlivý provoz PostgreSQL, časté relevantní maintenance obavy, které rozlišují ty, kdo mohou PostgreSQL provozovat v produkci, od těch, kdo narazí na zbytkovánou degradaci výkonu.