EXPLAIN viser PostgreSQL's spørreplankjøring — hvordan den vil kjøre en spørring (hvilke skanning, joins, indekser). EXPLAIN ANALYZE kjører faktisk spørringen og viser reell timing og radantall. Disse er de primære verktøyene for diagnostisering av treg spørringer.
EXPLAIN orders customer_id ;
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 er mer nyttig fordi den viser faktisk ytelse (reell timing, reelle radantall) — som avslører hvor spørringen virkelig bruker tid, ikke bare estimater.
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
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!
EXPLAIN og EXPLAIN ANALYZE er essensielle, primære verktøy for diagnostisering og optimalisering av treg spørringer i PostgreSQL — spørringsytelse er kritisk for applikasjoner, og disse verktøyene er hvordan du forstår hvorfor en spørring er treg og verifiserer rettelser, så det å mestre dem er viktig kunnskap på seniorvå for databaseytelsesarbeid.
Den grunnleggende verdien er synlighet inn i kjøringsplanen: i stedet for å gjette hvorfor en spørring er treg, avslører EXPLAIN ANALYZE (som kjører spørringen og viser reell timing og radantall) nøyaktig hvordan Postgres kjører den og hvor tiden brukes.
De viktigste tingene å gjenkjenne er skanningstatypene — spesielt å identifisere en Seq Scan (full tabellskanning) på en stor filtrert tabell, som vanligvis indikerer en manglende indeks (det vanligste og mest innvirkende spørringsytelsesproblemet), versus en rask Index Scan.
Å forstå hvordan man leser planen (skanningstyper, sammenligning av estimerte versus faktiske rader for å oppdage foreldet statistikk, identifisering av den dyreste noden som flaskehalsen, oppmerksomhet på sortering som spiller over på disk) er nøkkelkompetansen for spørringsoptimalisering.
Diagnostiseringsarbeidsflyten — kjør EXPLAIN ANALYZE, identifiser flaskehalsen (ofte en Seq Scan), påfør rettelsen (vanligvis å legge til en indeks), og kjør på nytt for å verifisere — er standardtilnærmingen, måleringsdreven, for spørringsoptimalisering.
Siden trege spørringer er en ledende årsak til dårlig databaseytelse, og siden EXPLAIN/EXPLAIN ANALYZE er verktøyene for diagnostisering av dem (som avslører manglende indekser, dårlige planer og flaskehalser) og verifisering av optimaliseringer, er det å mestre dem viktig, høy-verdikunnnskap for PostgreSQL-ytelse — det er hvordan du systematisk finner og fikser trege spørringer i stedet for å gjette, en kritisk kompetanse for ytelsesfulle databaser og et vanlig emne for databaseoptimaliseringsarbeid.