Volcano iterator model

Vectorized and Compiled Queries — Part 1
Imagine a volcano it is like a cone or at least it is drawn like that by most kids including me 😃. The below one is definitely not drawn by a kid.

As the shape of the volcano suggests lava(把岩浆比作data) is too much at the base and very less of it is fuming out of it.

Here is the non-fun wiki definition:

The Volcano model (originally known as the Iterator Model) is the ‘classical’ evaluation strategy of an analytical DBMS query: Each relational-algebraic operator produces a tuple stream, and a consumer can iterate over its input streams. The tuple stream interface is essentially: ‘open’, ‘next’ and ‘close’; all operators offer the same interface, and the implementation is opaque. Each ‘next’ call produces a new tuple from the stream, if one is available. To obtain the query output, one “next-next-next”s on the final RA operator; that one will in turn use “next”s on its inputs to pull tuples allowing it to produce output tuples, etc. Some “next”s will take an extremely long time, since many “next”s on previous operators will be required before they emit any output. Example: SELECT max(v) FROM t; may need to go trough all of t in order to find that maximum.

In easier words for the brain:

It is a chain of iterators and data flows through them when the topmost iterator calls next() on the iterator below it. Which results in propagation of .next() calls till the bottom-most iterator is called. Each iterator might apply some predicate or other operators. And as visualized in form of volcano data might get reduced as it flows up the iterator chain.