Definition
- A processing model defines how the DBMS executes a query plan and how it moves data from one operator to the next (
7:40). - Like row stores vs. column stores, the choice is a trade-off: one model suits OLTP, another suits OLAP (
7:40).
Two orthogonal mechanisms
- Control flow — how the DBMS tells an operator "it's your turn, produce output" (
8:11). - Data flow — where and how an operator sends its results (
8:47). - In the iterator model these two are deliberately blurred: the same mechanism that requests data (
next) is also the one used to say "stop, I have enough" (8:47,18:37).
What an operator emits
Depends on the model and storage layout (9:01, 9:14):
- The entire tuple, or a subset of attributes (natural for a column store).
- One tuple, all tuples, or some tuples.
The three models
| Model | Granularity | Prevalence |
|---|---|---|
| Iterator (Volcano / pipeline) | one tuple per call | the most common; "postgres, MySQL, Oracle, DB2, Mongo" (9:39) |
| Materialization | all tuples at once | very rare — "probably five systems in the world that I know of" (9:39) |
| Vectorized / batch | a batch of tuples | hybrid; dominant in OLAP for the last ~10 years — Snowflake, Databricks (10:07) |
A second, orthogonal decision
- Beyond the model itself: is data moved top-to-bottom (pull) or bottom-to-top (push)? This is independent of the processing model and is covered separately (
10:07).