Query Executor: From Plan Tree to Tuples
The planner draws the recipe.
The executor cooks it. PostgreSQL turns the chosen plan into a tree of running nodes, then repeatedly asks the root node for the next row until there are no more. Understanding that pull model is how you read EXPLAIN ANALYZE loops, startup vs total time, and why some nodes never run.
Pro members see the rest of this lesson
- A 4-step state diagram: Plan → Init → Pull → Measure
- The full mechanism: what PostgreSQL does internally, in source terms
- 1 SQL query you can run, each labelled by how it was verified
- The closing insight, the mistake it prevents, and what it changes in your work
Check it against the source3 citations in postgres/postgres · file, symbol and line verified on REL_17_STABLE
Primary symbol: ExecutorStart · line 121
Primary symbol: ExecInitNode · line 142
Primary symbol: PlanState · line 1113
Anchored to postgres/postgres on REL_17_STABLE and cross-checked against the manual for PostgreSQL 15–18. Every query here was run and its output captured on a throwaway PostgreSQL 17.10 lab; corrections are noted inline. Ch. 50 Overview of PostgreSQL Internals (Executor) in the official docs →
Connected
Where this lesson sits
What comes before, after, and alongside it.
Part of these pathways
Same learning track
Finished a free lesson?
Pro opens the rest of the engine course
You felt one mechanism. Pro is the full bodies, interview depth, and the tracks that build on this session.