EXPLAIN e ANALYZE

Ti sei mai chiesto come fa il database a scegliere se usare o meno quel bell'indice che gli hai appena creato? Non appena premi Invio su una Query (ad es una lunghissima Join con Group By a catena), il Query Planner (Planner) calcola al volo dozzine di strategie per portare a termine la query e seleziona il percorso ritenuto, in teoria, più veloce.

Ma come sviluppatore, devi saper guardare nella mente oscura del Query Planner.

EXPLAIN

Per scoprire come il Planner intende muoversi, basta mettere la parola magica EXPLAIN all'inizio della tua query.

EXPLAIN SELECT * FROM orders WHERE status = 'delivered';

Il risultato non saranno gli ordini! Ti verrà mostrato in output invece il piano (con statistiche stimate):

Seq Scan on orders  (cost=0.00..25.88 rows=15 width=40)
  Filter: (status = 'delivered'::text)

Questo ci dice:

1. Il Planner userà una Seq Scan (lettura brutale e sequenziale dal disco intero). Male se gli ordini sono miliardi.
2. Stima che verranno ritornate ~15 righe, e calcola i "Costi" in cicli CPU pre-caricati.

EXPLAIN ANALYZE

Mentre EXPLAIN si basa su ipotesi algoritmiche (basate sull'andamento statistico globale calcolato nelle ultime ore dei dati), EXPLAIN ANALYZE esegue esplicitamente la query sul serio (ed aspetta i risultati logici totali) e confronta in modo matematicamente assoluto il reale tempo effettivo.

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 90;

Index Scan using idx_orders_cust on orders  (cost=0.15..8.13 rows=4 width=40) (actual time=0.012..0.015 rows=4 loops=1)
  Index Cond: (customer_id = 90)
Planning Time: 0.081 ms
Execution Time: 0.033 ms

Evviva! Qui impari che il database ha deciso di applicare l'Index Scan sul nostro indice secondario idx_orders_cust, impiegando un esecuzione microscopica di un millesimo di secondo, saltando milioni di row al volo.

Prova tu

Ottenere metriche veritiere