A pipeline of one-way steps
Which planning stages are certain and which are risky, and how late can the uncertain decisions be put off?
Planning is a pipeline. Each stage fixes something the next stage needs and cannot reconsider: you cannot rewrite a query until names are resolved to real tables, you cannot match rules until the expression has a standard form, you cannot compute costs until a physical alternative exists, and you cannot choose a join order until you can compute costs. Every stage narrows the options.
Now sort the stages by the information they demand. The early stages need nothing but the schema, and they are always right. The late stages need statistics, and they are often wrong. The whole design problem is how late the uncertain decisions can be put off without making the search impossible. For most of the planner the answer is "not at all", which is why adaptive execution exists (Execution decisions).
| Stage | What it fixes | Information needed | Can it be wrong? | Typical failure |
|---|---|---|---|---|
| Parse | Syntax | None | No | — |
| Analyze / bind | Names become objects; types | The catalog | No | Plans invalidated by schema changes (DDL) |
| Normalize | A canonical form | Schema | No | Exponential blowup; structure lost |
| Rewrite (rules) | Algebraic shape | Schema and constraints | Only in corner cases | An illegal rewrite when NULLs are present |
| Enumerate | The set of candidate plans | Schema | Silently | Space too big, so a heuristic is used |
| Cost | The chosen plan | Statistics | Without bound | Wrong operator or wrong order |
Note where the boundary sits. Everything above "enumerate" is certain, cheap and unconditional. Everything at or below it is the risky part. Most of what practitioners call "optimizer tuning" is aimed at the bottom row, and most of the real leverage is in the middle three rows.