Module mz_sql::plan::lowering

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.

Structs

• ColumnMap 🔒
  Maps a leveled column reference to a specific column.
• Config
• CteDesc 🔒
  Information about needed when finding a reference to a CTE in scope.
• OnPredicates 🔒
  A struct that represents the predicates in the on clause in a form suitable for efficient planning outer joins with equijoin predicates.

Enums

• JoinKeys 🔒
  A set of join keys referencing an input.
• OnPredicate 🔒

Traits

• LoweringExt 🔒
  Extension methods for MirRelationExpr required in the HIR ⇒ MIR lowering code.

Functions

• apply_existential_subquery 🔒
• apply_scalar_subquery 🔒
• attempt_outer_equijoin 🔒
  Attempts an efficient outer join, if on has equijoin structure.
• branch 🔒
  Prepare to apply inner to outer. Note that inner is a correlated (SQL) expression, while outer is a non-correlated (dataflow) expression. inner will, in effect, be executed once for every distinct row in outer, and the results will be joined with outer. Note that columns in outer that are not depended upon by inner are thrown away before the distinct, so that we don’t perform needless computation of inner.

Type Aliases

• CteMap 🔒
  Map with the CTEs currently in scope.