Skip to main content

Module sqlplan

Module sqlplan 

Source
Expand description

The execution plan — what the evaluator actually did, and how to render it.

§Why this exists

Before this, parsing, semantics, optimisation and execution all lived in one growing function. That is survivable while there is one execution strategy and no rewrites; it stops being survivable the moment a query can be run more than one way, because there is then no place to record WHICH way was chosen or WHY.

This is deliberately not a PostgreSQL planner. There is no cost model, no statistics, and no search over join orders. It is a record of the pipeline that ran, with the real row counts it moved.

§The plan is EMITTED by execution, never written alongside it

Every node here is appended by the executor as it does the work, and the row counts are the counts it actually observed. That is a design constraint, not an implementation detail: a plan assembled independently of the executor can drift out of agreement with it, and an EXPLAIN that confidently describes a pipeline the engine did not run is worse than having no EXPLAIN at all — it sends the reader to optimise a query shape that never existed.

For the same reason it is stored as a PIPELINE (a Vec of stages) rather than a tree: the executor is a pipeline — materialise, join, filter, project, sort, paginate — and a tree structure would imply a generality it does not have.

The one exception is a join, which genuinely has two inputs, and Plan::render accounts for that by printing them as siblings. Getting that wrong is not cosmetic: the first version indented the two scans differently, which reads as “the left relation was scanned inside the scan of the right one” — a claim about the execution that was simply false.

§Consequently, EXPLAIN here always reports actual rows

PostgreSQL’s bare EXPLAIN estimates without executing, and EXPLAIN ANALYZE executes and reports reality. NEDB has no statistics to estimate from, so an estimate would be a guess dressed as a number. It executes and reports what happened. Stated in the output so nobody mistakes one for the other.

Structs§

Plan
What ran, in the order it ran.

Enums§

PlanTree
The pipeline as a TREE, which is what it actually is.
Stage
One stage of the pipeline that ran.