Documentation
¶
Overview ¶
Package exec drives a physical operator tree to completion.
It is a SERIAL driver, and it stayed one. This doc used to say "the seam where morsel-driven parallelism arrives in v0.2 is here and only here", and step 5 put parallelism somewhere else entirely: physical.parallelOp wraps the pipeline below this loop, so a query runs on N threads without exec knowing. The prediction was wrong about the place, and the reason is worth keeping — parallelOp's round-robin dispatch is what BUYS input order structurally, and a scheduler here would have to re-establish it, which is the harder problem.
What is still true: nothing here knows about spilling or temporary files. Every one of those lives below, which is why three operators gained the ability to spill without this file changing. The one budget here is the result's: Collect holds every batch, and nothing below it can.
Each loop pulls through physical.Pull, so a panic below the root is an error. With one thread every operator runs on the caller's goroutine, and a panic there escaped every entry point until step 72.
Index ¶
- func Batches(ctx context.Context, root physical.Operator) iter.Seq2[*data.Batch, error]
- func Collect(ctx context.Context, root physical.Operator, held *execopt.Account) (*data.Batch, error)
- func Count(ctx context.Context, root physical.Operator) (int64, error)
- func Schema(root physical.Operator) *dtype.Schema
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Batches ¶
Batches streams results without materialising the whole frame.
The iterator yields (batch, nil) until the stream ends, or (nil, err) once on failure and then stops. Breaking out of the range loop closes the operator tree, which is what makes an early `break` safe.
func Collect ¶
func Collect(ctx context.Context, root physical.Operator, held *execopt.Account) (*data.Batch, error)
Collect runs the tree to completion and concatenates every batch.
held is the account the result is held in, from execopt.Budget.Result; nil holds it unchecked. Each batch is retained in it as it arrives, and Collect stops with held's error once the query holds more than a result may take.
held is released once the stream has ended, before the batches are concatenated. The ledger's keys are pointers into the buffers it counts, so an account keeps alive what it holds: released after, it kept every batch until the result was whole, and the result was held twice while it was copied (step 131).
Types ¶
This section is empty.
Source Files