pub struct PhysicalPlan {
pub sources: Vec<PlannedSource>,
pub residuals: Vec<Option<BoundExpr>>,
pub constant_filter: Option<BoundExpr>,
pub select: BoundSelect,
pub aggregation: AggregationMode,
pub needs_sort: bool,
pub reverse: bool,
pub grouped_walk: bool,
pub distinct_walk: bool,
pub compounds: Vec<(CompoundOp, PhysicalPlan)>,
pub levers: Levers,
pub subqueries: bool,
}Expand description
A physical plan for a read-only statement.
Fields§
§sources: Vec<PlannedSource>The FROM terms, in the order the nested loops visit them.
residuals: Vec<Option<BoundExpr>>The predicates the loops must still evaluate, one per nesting level.
A predicate is attached to the innermost term it reads, so it is tested as soon as it can be rather than after every loop has been entered.
constant_filter: Option<BoundExpr>A predicate over no columns at all, tested once before the loops.
select: BoundSelectThe bound statement the plan came from.
aggregation: AggregationModeHow the rows are aggregated.
needs_sort: boolWhether the results have to pass through a sorter.
reverse: boolWhether the outermost term is walked backwards.
A B-tree read from its last entry to its first produces exactly the
reverse of what it produces read forwards, so a descending ORDER BY
over an ascending structure is a direction rather than a sort. Only ever
set when needs_sort is false: a plan that sorts
does not care which way its input arrived.
grouped_walk: boolWhether the walk already brings the rows of each group together.
Grouping needs adjacency, not order: if every row of a group arrives
before the next group starts, the aggregate can be finished and emitted
as the key changes and nothing has to be collected first. A walk whose
leading keys are exactly the GROUP BY columns delivers that, whichever
direction it runs in.
distinct_walk: boolWhether the walk already brings duplicate result rows together.
The same property for DISTINCT: adjacent duplicates can be dropped by
comparing each row with the one before it, where a set has to remember
every row it has seen.
compounds: Vec<(CompoundOp, PhysicalPlan)>The later arms of a compound, each with the operator that joined it.
levers: LeversWhich optimizations were on when this plan was chosen.
Carried on the plan rather than looked up by the executor, because a plan is cached and a lever that changed after it was built must not change what it does - a plan that consulted the connection at execution time would answer one way today and another tomorrow with no recompilation in between. The connection throws its compiled statements away when a lever moves, which is what makes this field the truth.
subqueries: boolWhether any expression in this plan holds a subquery used as a value.
Decided here because it is a property of the statement and not of the
data, and because the alternative was deciding it per execution: the
executor folds uncorrelated subqueries on the way into each run, and it
has to ask this question first every time. Walking the expression tree
to ask it cost about 0.07 us per execution - measurable against a
point.rowid that takes 0.78 - because BoundExpr::children allocates
a vector per node. Asked once per compiled statement instead, it costs
nothing a statement runs.
Implementations§
Source§impl PhysicalPlan
impl PhysicalPlan
Sourcepub fn max_source_id(&self) -> usize
pub fn max_source_id(&self) -> usize
Returns the highest statement-wide source id anywhere in the plan.
The compiler sizes its cursor map from this, so a nested block’s cursor has a slot before the block that encloses it is compiled.