-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
Is your feature request related to a problem or challenge?
In the existing code base we have two different methods to keep track of equivalences in the Arc<dyn PhysicalPlan>.
Which are equivalence_properties and ordering_equivalence_properties.
As a background EquivalenceProperties keeps track of equivalent columns such as a=b=c, e=f.
OrderingEquivalenceProperties alternative orderings that table satisfies. such [a ASC, b ASC], and [c ASC, d ASC].
OrderingEquivalenceProperties keeps track of constant expressions also (e.g expression that are known to have a constant value. This can arise after filter, join, etc.).
Inherently, this information is coupled, as an example
Assume that
- existing table satisfies following orderings
[a ASC, b ASC]and[c ASC, d ASC]. - table have equivalent columns
a=e. - It is known that
fis constant.
If an operator requires ordering at its input [e ASC, f ASC, b ASC]. During the analysis for whether this requirement is satisfied by existing ordering, we need to consider all orderings, equivalences, and constants at the same time.
Following naive algorithm can be followed for this analysis (Please note that algorithm in this PR is more elaborate.)
- Remove constant expressions from the requirement (This converts requirement
[e ASC, f ASC, b ASC]to[e ASC, b ASC]) - Rewrite requirement such that it uses only representative expression for each distinct equivalent group (This converts requirement
[e ASC, b ASC]to[a ASC, b ASC]). - Apply same procedures above each of the orderings inside the
OrderingEquivalences(This converts ordering[a ASC, b ASC]to[a ASC, b ASC]and[c ASC, d ASC]to[c ASC, d ASC]no change ). - Check whether normalized requirement
[a ASC, b ASC]is satisfied by any of normalized orderings[a ASC, b ASC],[c ASC, d ASC].
As can be seen from the example above. Keeping track of these information separately, is a bit cumbersome.
Also for the user implementing new functionality is a bit hard, and existing APIs are a bit involved also. Such as ordering_satisfy, requirements_compatible, etc.
I think it is better to unify these information in a single struct so that
- We can expose better, and more friendly
APIs from struct. - Move utils, functions, to method calls
- Keep the invariants in the state (not relying on correct arguments).
- All of the implementations, algorithms resides in a single place, and logic is not scatterred in different files.
TASKS
- Add Unification of these classes. Completed in #8006
- Encapsulate
ProjectionMappingas a struct #8033 - Internal error with repartitioning after equivalence consolidation #8043
- Preserve all of the valid orderings during merge, see #8169.
- Add support for complex expression ordering analysis. We should be able to understand
date_bin(ts)is ordered giventsis ordered. See #8484. - Overlapping
ExecutionPlan::maintains_input_order(), equivalence_properties and maintains_input_orderare confusing #8120 to maybe help avoid issues for others upgrading - Encapsulate
EquivalenceClassinto a struct #8034
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response