Query plan / EXPLAIN

A query plan is the database's chosen route from SQL to rows: which table to read first, whether to scan or use an index, how to join, and where to sort or aggregate. PostgreSQL's EXPLAIN shows the estimated plan. EXPLAIN ANALYZE actually runs the statement and adds real row counts and timings, which is how you see where the estimate and reality parted ways.

Reach for it before adding an index or rewriting a slow query. Read the tree from the deepest nodes outward, then compare estimated rows with actual rows and loops: a node with loops in the thousands is doing the same work over and over. EXPLAIN (ANALYZE, BUFFERS) adds shared buffer hits and reads, so you can also see how much of that work touched cache versus disk. Nobody reads a large plan as raw text for long: run EXPLAIN (ANALYZE, FORMAT JSON) and paste the output into explain.dalibo.com or explain.depesz.com, which highlight the expensive node and the worst row estimate for you.

Gotcha: cost is the planner's internal score, not milliseconds, and a sequential scan is not automatically bad when most of a table is needed. Large estimate errors are often the more useful clue because they can send the planner toward the wrong join or scan. Also remember that EXPLAIN ANALYZE executes the statement, including INSERT, UPDATE, and DELETE, so test write plans inside a transaction you roll back.