Expand description
Lowering is the process of transforming a HirRelationExpr
into a MirRelationExpr
.
The most crucial part of lowering is decorrelation; i.e.: rewriting a
HirScalarExpr
that may contain subqueries (e.g. SELECT
or EXISTS
)
with instances of MirScalarExpr
that contain none of these.
Informally, a subquery should be viewed as a query that is executed in the context of some outer relation, for each row of that relation. The subqueries often contain references to the columns of the outer relation.
The transformation we perform maintains an outer
relation and then
traverses the relation expression that may contain references to those
outer columns. As subqueries are discovered, the current relation
expression is recast as the outer expression until such a point as the
scalar expression’s evaluation can be determined and appended to each
row of the previously outer relation.
It is important that the outer columns (the initial columns) act as keys for all nested computation. When counts or other aggregations are performed, they should include not only the indicated keys but also all of the outer columns.
The decorrelation transformation is initialized with an empty outer relation, but it seems entirely appropriate to decorrelate queries that contain “holes” from prepared statements, as if the query was a subquery against a relation containing the assignments of values to those holes.
Modules§
Structs§
- Maps a leveled column reference to a specific column.
- Context 🔒Context passed to the lowering. This is wired to most parts of the lowering.
- CteDesc 🔒Information about needed when finding a reference to a CTE in scope.
- A struct that represents the predicates in the
on
clause in a form suitable for efficient planning outer joins with equijoin predicates.
Enums§
- Join
Keys 🔒A set of join keys referencing an input.
Traits§
- Extension methods for
MirRelationExpr
required in the HIR ⇒ MIR lowering code.
Functions§
- Attempts an efficient outer join, if
on
has equijoin structure. - branch 🔒Prepare to apply
inner
toouter
. Note thatinner
is a correlated (SQL) expression, whileouter
is a non-correlated (dataflow) expression.inner
will, in effect, be executed once for every distinct row inouter
, and the results will be joined withouter
. Note that columns inouter
that are not depended upon byinner
are thrown away before the distinct, so that we don’t perform needless computation ofinner
.
Type Aliases§
- CteMap 🔒Map with the CTEs currently in scope.