How Queries Execute
RQL uses a volcano-style execution model. Your query compiles to a pipeline of operators that pull data one row at a time.
Pipeline Model
Every transform in your query becomes an operator in a pipeline. Operators are chained together — each one pulls rows from the one below it.
This query compiles to: ScanOp → FilterOp → ExtendOp → SortOp → TakeOp. Five operators, one pipeline.
Top to Bottom
Your query reads top to bottom. The engine executes it the same way. No nested subqueries, no inside-out reading. One line, one step.
Lazy Evaluation
Nothing runs until a consumer pulls. If you take 5, the pipeline stops after producing 5 rows — even if the source table has millions. Only the operators needed to satisfy the result actually execute.
Streaming
Rows flow through the pipeline without materializing full intermediate results. A filter doesn't build a temporary table of passing rows — it passes each row through immediately. The exceptions are operators that need all their input before producing output: sort and aggregate. These buffer internally.
Execution Phases
- Parse — RQL text to AST
- Plan — AST to operator DAG
- Resolve Types — infer and check types across the pipeline
- Execute — pull rows through the operator chain
The full pipeline in action — scan, filter, aggregate, sort.