Expand description
Whole-dataflow optimization
A dataflow may contain multiple views, each of which may only be optimized locally. However, information like demand and predicate pushdown can be applied across views once we understand the context in which the views will be executed.
Structs§
- Extra information about the dataflow. This is not going to be shipped, but has to be processed in other ways, e.g., showing notices to the user, or saving meta-information to the catalog.
- This struct will save info about parent nodes as we are descending down a
MirRelationExpr
. We always start with filling inusage_type
when we see an operation that uses an arrangement, and then we fill inrequested_keys
when we see anArrangeBy
. So, the pattern that we are looking for is
Functions§
- Pick an index from a given Vec of index keys.
- Inline views used in one other view, and in no exported objects.
- Optimizes the implementation of each dataflow.
- Pushes demand information from published outputs to dataflow inputs, projecting away unnecessary columns.
- Pushes demand through views in
view_sequence
in order, removing columns not demanded. - Pushes predicate to dataflow inputs.
- Pushes filters down through views in
view_sequence
in order. - Propagates information about monotonic inputs through operators, using
mz_repr::optimize::OptimizerFeatures
fromctx
forcrate::analysis::Analysis
. - Performs either the logical or the physical optimization pass on the dataflow using the supplied set of indexes.
- Restricts the indexes imported by
dataflow
to only the ones it needs. It also adds to theDataflowMetainfo
how each index will be used. It also annotates globalGet
s with whether they will be reads from Persist or an index, plus their index usage types.