Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Sort Based Optimizations #8064

Open
6 of 7 tasks
mustafasrepo opened this issue Nov 6, 2023 · 0 comments · Fixed by #8169
Open
6 of 7 tasks

Improve Sort Based Optimizations #8064

mustafasrepo opened this issue Nov 6, 2023 · 0 comments · Fixed by #8169
Labels
enhancement New feature or request

Comments

@mustafasrepo
Copy link
Contributor

mustafasrepo commented Nov 6, 2023

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

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant