mustafasrepo opened a new issue, #8064: URL: https://github.com/apache/arrow-datafusion/issues/8064
### 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 `API`s 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. ### Describe the solution you'd like _No response_ ### Describe alternatives you've considered _No response_ ### Additional context _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
