Storage, Execution & Recovery Internals
Query Lifecycle and Iterator Execution
A query moves from syntax through name/type binding, semantic rewriting and physical planning into an executor tree. In the classic pull iterator model, each parent asks a child for the next tuple, so access, filtering, joining, grouping, and projection compose without materializing every intermediate.
- Parsing is not semantic validation.
- Rewrites must preserve observable semantics.
- Planning chooses executable properties.
- Pull iterators compose open/next/close.
- Rescan and parameterization multiply work.
- Vectorized and push engines change granularity.
| Operator | Pipeline behavior | Key consequence |
|---|---|---|
| Scan/filter/project | Usually streaming | Early selectivity reduces upstream work |
| Nested loop | Streaming but rescans inner | Tiny estimate miss can multiply cost |
| Hash join/aggregate | Build/state then output | Memory and spill depend on actual width/rows |
| Sort | Blocking | Startup latency and external runs |
| Materialize | Stores reusable result | Avoids rescan at memory/temp-I/O cost |