Što je VACUUM i zašto je važan?

Question

Accepted Answer

**`VACUUM`** je PostgreSQL-ov proces održavanja koji vraća pohranu iz **mrtvih tuples** (zastarjelih verzija redaka koje ostavlja MVCC) i ažurira statistiku. Budući da Postgres MVCC stvara mrtve redake pri svakom UPDATE/DELETE, VACUUM je neophodan za sprječavanje **bloata** i održavanje baze zdravom. **Autovacuum** ga automatizira.

## Zašto postoje mrtvi tuples (veza s 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.
```

## Što VACUUM radi

```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 — automatsko održavanje

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

## Znakovi problema s vacuum-om

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

## Zašto je važno

Razumijevanje VACUUM-a važno je za **ispravan rad PostgreSQL-a** jer je direktna posljedica Postgres-ovog MVCC arhitekture i bitno je za zdravlje baze — zanemarivanje je uzrokuje pravi, ozbiljan probleme performansi i pogona.

Osnovnom povezanost je da **MVCC stvara mrtve tuples** (zastarjele verzije redaka) pri svakom UPDATE i DELETE, i oni se akumuliraju kao **bloat** (nezauzeta prostor, sporiji skenovi, snižene performanse) osim ako se ne očiste — VACUUM je to čišćenje, vraćanje prostora mrtvih tuples i održavanje tablica kompaktnih i upita bržih.

Razumijevanje varijanti — redoviti `VACUUM` (vraća prostor za ponovnu upotrebu, redovito održavanje, bez teškog zaključavanja), `VACUUM FULL` (u potpunosti vraća prostor operacijskom sustavu ali prepisuje i zaključava tablicu, pa se koristi rijetko), i `ANALYZE` (ažurira statistiku pa query planer donosi dobre odluke) — važno je za održavanje.

Znanje o **autovacuum-u** (automatskomu processu u pozadini koji obavlja redovito vacuum-iranje, koji obično ostavljate uključenim ali možda trebate *prilagoditi* za tablice s puno pisanja kako ne bi zaostao) je ključno operacijsko znanje.

Prepoznavanje **znakova problema s vacuum-om** (bloat tablica/indeksa, zastarjela statistika koja uzrokuje loše query planove, i ozbiljna rizika od transaction ID wraparound-a ako je vacuum ozbiljno zanemaren) i kako ih nadgledati važno je za održavanje zdravih produkcijskih baza.

Budući da je VACUUM Postgres-specifična operacijska nužnost (koja proizlazi izravno iz MVCC), i budući da zanemarivanje uzrokuje bloat, spore upite, loše planove, pa čak i kritične wraparound probleme, razumijevanje VACUUM-a — zašto je potreban (MVCC mrtvi tuples), što varijante rade, autovacuum, i znakovi problema — važno je znanje razine seniora za pouzdani rad PostgreSQL-a, često relevantna briga za održavanje koja razlikuje one koji mogu pokrenuti Postgres u produkciji od onih koji padaju u izbježivih degradacija performansi.