Kako koristiš EXPLAIN i EXPLAIN ANALYZE?

Question

Accepted Answer

**`EXPLAIN`** pokazuje **plan izvršavanja upita** PostgreSQL-a — kako će izvršiti upit (koji skenovi, spojevi, indeksi). **`EXPLAIN ANALYZE`** zapravo izvršava upit i pokazuje stvarno vrijeme i broj redaka. Ova su alata primarni alati za dijagnostiku sporih upita.

## EXPLAIN — plan (bez izvršavanja)

```sql
EXPLAIN SELECT * FROM orders WHERE customer_id = 5;
-- shows the PLAN: scan type, estimated cost, estimated rows — but doesn't run it
```

## EXPLAIN ANALYZE — plan sa STVARNIM podacima izvršavanja

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- ACTUALLY runs it → shows REAL time, ACTUAL rows, and where time was spent
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;   -- also shows buffer/cache usage
```

`EXPLAIN ANALYZE` je korisniji jer pokazuje *stvarnu* performansu (stvarno vrijeme, stvaran broj redaka) — otkrivajući gdje upit zaista troši vrijeme, ne samo procjene.

## Čitanje plana: ključne stvari za koje trebam paziti

```text
SCAN TYPES (most important):
  Seq Scan      → FULL TABLE SCAN (reads every row) — slow on big tables, often the problem
  Index Scan    → uses an index to find rows — fast
  Index Only Scan → reads only the index (doesn't touch the table) — fastest
  Bitmap Scan   → for combining indexes / many matches

WATCH FOR:
  ✗ Seq Scan on a large table being filtered → likely a MISSING INDEX
  ✗ Estimated rows VERY different from actual rows → outdated statistics (run ANALYZE)
  ✗ Expensive joins, sorts spilling to disk ("external merge")
  ✗ The node with the highest actual time = the bottleneck
```

## Primjer dijagnostike

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Seq Scan on orders ... actual time=120ms" → a full scan, slow

CREATE INDEX idx_orders_customer ON orders(customer_id);

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Index Scan using idx_orders_customer ... actual time=0.05ms" → fixed!
```

## Zašto je važno

`EXPLAIN` i `EXPLAIN ANALYZE` su bitni, primarni alati za **dijagnostiku i optimizaciju sporih upita** u PostgreSQL-u — performansa upita je kritična za aplikacije, i ovi alati su kako razumiješ *zašto* je upit spora i kako potvrdiš ispravke, pa je savladavanje njih važno znanje na seniorskoj razini za rad na performansama baze podataka.

Temeljna vrijednost je **vidljivost u plan izvršavanja**: umjesto pogađanja zašto je upit spora, `EXPLAIN ANALYZE` (koji izvršava upit i pokazuje stvarno vrijeme i broj redaka) otkriva točno kako Postgres izvršava i gdje se vrijeme troši.

Najvažnije stvari za prepoznavanje su **tipovi skeniranja** — posebno identificiranje **`Seq Scan` (skena cijele tablice)**  na velikoj filtrinoj tablici, što obično ukazuje na **nedostajući indeks** (najčešći i najutjecajniji problem performanse upita), u odnosu na brz **`Index Scan`**.

Razumijevanje kako čitati plan (tipovi skeniranja, usporedba procijenjenih naspram stvarnih redaka za pronalaženje zastarjelih statistika, identificiranje najskupljeg čvora kao grla, praćenje sortiranja koja prelijevaju na disk) je ključna vještina za optimizaciju upita.

Dijagnostički tijek rada — pokreni `EXPLAIN ANALYZE`, identificiraj grlo (često Seq Scan), primijeni ispravku (obično dodavanje indeksa), i pokreni ponovno za potvrdu — je standardan, pristup vođen mjerenjima za optimizaciju upita.

Budući da su spori upiti vodeći uzrok loše performanse baze podataka, i budući da su `EXPLAIN`/`EXPLAIN ANALYZE` *alati* za njihovu dijagnostiku (otkrivajući nedostajuće indekse, loše planove i grla) i potvrdu optimizacija, savladavanje njih je važno, visoke vrijednosti znanja za PostgreSQL performansu — to je kako sistematski pronalazis i popravljas spore upite umjesto pogađanja, kritična vještina za performantne baze podataka i česta tema za rad na optimizaciji baza podataka.