How the Cost-Based Optimizer Chooses a Plan
There's always more than one way to run a query: different ways to read a table, different orders to join tables.
The planner sketches the promising options, guesses how expensive each would be, and runs the cheapest. It doesn't test every combination, or it would spend longer planning than running.
Pro members see the rest of this lesson
- A 4-step state diagram: Enumerate → Cost → Prune → Join
- The full mechanism: what PostgreSQL does internally, in source terms
- 1 transcript captured on PostgreSQL 17.10
- The closing insight, the mistake it prevents, and what it changes in your work
Card required. Cancel before day 7 and you are not charged.
Check it against the source5 citations in postgres/postgres · file, symbol and line verified on REL_17_STABLE
Primary symbol: standard_planner · line 288
Primary symbol: make_one_rel · line 171
Primary symbol: join_search_one_level · line 73
Primary symbol: cost_seqscan · line 284
Primary symbol: geqo · line 72
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. §50.1 Overview of the Planner/Optimizer 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.