Hoe gebruik je EXPLAIN en EXPLAIN ANALYZE?

Question

Accepted Answer

**`EXPLAIN`** toont PostgreSQL's **query execution plan** — hoe het een query zal uitvoeren (welke scans, joins, indexes). **`EXPLAIN ANALYZE`** voert de query daadwerkelijk uit en toont echte timing en rij aantallen. Dit zijn de primaire tools voor het diagnosticeren van trage queries.

## EXPLAIN — het plan (zonder uit te voeren)

```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 — het plan met ECHTE execution data

```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` is nuttiger omdat het *werkelijke* performance toont (echte timing, echte rij aantallen) — het onthult waar de query echt tijd doorbrengt, niet alleen schattingen.

## Het plan lezen: de belangrijkste dingen om op te letten

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

## Een diagnostisch voorbeeld

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

## Waarom het belangrijk is

`EXPLAIN` en `EXPLAIN ANALYZE` zijn essentiële, primaire tools voor **het diagnosticeren en optimaliseren van trage queries** in PostgreSQL — query performance is kritiek voor applicaties, en deze tools zijn hoe je begrijpt *waarom* een query traag is en fixes verifieert, dus het beheersen ervan is belangrijk senior-level kennis voor database performance werk.

De fundamentele waarde is **zichtbaarheid in het execution plan**: in plaats van gokken waarom een query traag is, onthult `EXPLAIN ANALYZE` (die de query uitvoert en echte timing en rij aantallen toont) precies hoe Postgres het uitvoert en waar tijd wordt besteed.

De belangrijkste dingen om te herkennen zijn de **scan types** — vooral het identificeren van een **`Seq Scan` (volledige tabelscan)** op een grote gefilterde tabel, wat meestal wijst op een **ontbrekende index** (het meest voorkomende en impactvolle query performance probleem), versus een snelle **`Index Scan`**.

Begrijpen hoe je het plan leest (scan types, vergelijken van geschatte versus werkelijke rijen om verouderde statistieken op te sporen, het meest kostbare knooppunt als bottleneck identificeren, letten op disk-spilling sorts) is de sleutelvaardighed voor query optimalisatie.

De diagnostische workflow — run `EXPLAIN ANALYZE`, identificeer de bottleneck (vaak een Seq Scan), pas de fix toe (meestal het toevoegen van een index), en run opnieuw om te verifiëren — is de standaard, measurement-driven aanpak voor query optimalisatie.

Omdat trage queries een leidende oorzaak zijn van slechte database performance, en omdat `EXPLAIN`/`EXPLAIN ANALYZE` *de* tools zijn voor het diagnosticeren ervan (ontbrekende indexes, slechte plans en bottlenecks onthullend) en optimalisaties verifiëren, is het beheersen ervan belangrijke, waardevolle kennis voor PostgreSQL performance — het is hoe je systematisch trage queries vindt en reparaert in plaats van te gokken, een kritieke vaardigheid voor performante databases en een veelvoorkomend onderwerp voor database optimalisatie werk.