You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 f is 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
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
andordering_equivalence_properties
.As a background
EquivalenceProperties
keeps track of equivalent columns such asa=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
[a ASC, b ASC]
and[c ASC, d ASC]
.a=e
.f
is 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.)
[e ASC, f ASC, b ASC]
to[e ASC, b ASC]
)[e ASC, b ASC]
to[a ASC, b ASC]
).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 ).[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 thatAPI
s from struct.TASKS
ProjectionMapping
as a struct #8033date_bin(ts)
is ordered givents
is ordered. See #8484.ExecutionPlan::maintains_input_order(), equivalence_properties and maintains_input_order
are confusing #8120 to maybe help avoid issues for others upgradingEquivalenceClass
into a struct #8034Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: