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.