How Postgres executes a query

The five stages

Your SQL string is not run directly. The Postgres backend that owns your connection pushes it through a pipeline:

1. Parse — the raw text is checked for syntax and turned into a parse tree. A missing comma or SELCT dies here. No tables are touched yet; the parser doesn’t even know if orders exists.
2. Analyze (semantic) — names are resolved against the catalog. Does orders exist? Does it have a column id? What types are involved? A “column does not exist” error comes from here, not the parser.
3. Rewrite — rule-based transformations apply. The big one: a query against a view is rewritten to hit the underlying tables; row-level security policies and rules are injected here too.
4. Plan / optimize — the planner takes the analyzed query tree and produces a physical plan: which scan (sequential? index?), which join algorithm (nested loop? hash? merge?), in which order. It uses table statistics to estimate row counts and picks the cheapest plan by an internal cost model.
5. Execute — the executor walks the chosen plan tree, pulling rows through it node by node, and streams the result back to you.

Together these five stages mean that by the time a row reaches you, it has been validated, resolved, transformed, optimized, and fetched — and each of those steps can fail independently. Skipping any one of them in your mental model leaves you guessing when something goes wrong.

Why the stages matter for debugging

When a query misbehaves, most engineers rewrite it first — and often waste an hour changing text that was never the problem. The pipeline gives you a faster path: match the symptom to the stage, fix at that stage, done.

The pipeline is a diagnostic map. Match the symptom to the stage:

• Syntax error → parse stage. Pure text problem; the schema is irrelevant.
• “relation/column does not exist” → analyze stage. The text is valid SQL but doesn’t match the catalog.
• Query suddenly slow after a data load → plan stage. The planner’s row estimates went stale, so it picked a bad plan. The fix is usually ANALYZE to refresh statistics — not rewriting the query.
• Query always slow, plan looks right → execute stage. The plan is fine but it’s genuinely reading too many pages; the fix is an index or less data, which changes what plans are available.

This is why the senior reflex is EXPLAIN. EXPLAIN <query> shows you the plan the planner chose without running it; EXPLAIN ANALYZE <query> runs it and shows estimated vs actual rows at each node. The gap between estimate and actual is the single most useful number in Postgres performance work — it tells you whether the planner was lied to by stale statistics.

-- See the plan only (fast, no execution):
EXPLAIN SELECT * FROM orders WHERE id = 42;

-- Run it and compare estimate vs reality:
EXPLAIN ANALYZE SELECT * FROM orders WHERE id = 42;

You won’t fully read a plan yet — that’s an entire unit later (08-internals-and-tuning) and the databases track covers the planner and execution-plan internals in depth. For now, internalize only the shape: text in, five stages, rows out, and EXPLAIN is your window into stage four.