The Volcano iterator model of query execution

WHY IT EXISTS A query optimizer produces a plan as a tree of relational operators. The Volcano model gives every operator the same simple interface so plans can be built by composing operators arbitrarily, decoupling each operator's logic from its neighbors.

THE MENTAL MODEL Each operator, scan, filter, join, aggregate, sort, implements three methods: open to initialize, next to produce the next tuple, and close to clean up. The plan is a tree; the consumer at the top pulls data downward. It is demand-driven, also called pull-based.

HOW DATA FLOWS The root operator's next is called, which calls next on its child to get an input tuple, which calls next on its child, and so on down to the leaf scans that read from storage. A tuple produced by a leaf flows upward, transformed by each operator, until one result row emerges at the top. Calling next again repeats the process for the next row. Blocking operators like sort or hash-build must consume all input before producing output, breaking the pipeline at that point.

ADVANTAGES Uniformity and composability: any operator can feed any other through the identical iterator interface, simplifying the engine. Pipelining: non-blocking operators stream tuples through without materializing full intermediate tables, so memory stays low and the first result can appear quickly.

LIMITATIONS AND FOLLOW-UPS The cost is overhead: one virtual function call per tuple per operator dominates CPU on large scans, which is why modern engines move to vectorized or compiled execution. Expect follow-ups on pull versus push models, how vectorization fixes the overhead, and what makes an operator blocking.

ONE CONCRETE EXAMPLE For SELECT name FROM users WHERE age greater than 30, the plan is Project over Filter over Scan. Project.next calls Filter.next, which calls Scan.next to read a row; Filter discards rows failing the predicate and passes qualifying ones up, where Project trims to the name column, yielding one output row per call.