Skip to content

Improve Sort Based Optimizations #8064

@mustafasrepo

Description

@mustafasrepo

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions