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?
Consider a use case where required ordering is (a ASC,b ASC), and existing ordering is (a ASC).
As an example input is like following
a
b
1
2
1
3
1
1
2
2
2
3
2
1
expected output is like following
a
b
1
1
1
2
1
3
2
1
2
2
2
3
If we were to use information about existing ordering. We could buffer up a values until it changes like below
a
b
1
2
1
3
1
1
when 2 is received for the value of a. We could then sort subtable according to desired ordering (b ASC), then emit following result
a
b
1
1
1
2
1
3
I think this operator
Enable us to use SortExec without breaking pipeline for some use cases (for this behavior we can write a new operator also).
Decrease the memory usage of the SortExec when input ordering satisfy a prefix of the desired ordering.
Describe the solution you'd like
No response
Describe alternatives you've considered
This should be a new operator or current SortExec can be extended to behave this way.
However, I do think that extending current SortExec to behave this way is better option because:
Existing plans will immediately benefit from this change (otherwise we need to write a rule to choose between SortExec and new PartialSortExec)
less change will be introduced to code base. Since I presume, the two operators will have lots of code common anyway.
Is your feature request related to a problem or challenge?
Consider a use case where required ordering is
(a ASC,b ASC)
, and existing ordering is(a ASC)
.As an example input is like following
expected output is like following
If we were to use information about existing ordering. We could buffer up a values until it changes like below
when 2 is received for the value of
a
. We could then sort subtable according to desired ordering (b ASC), then emit following resultI think this operator
SortExec
without breaking pipeline for some use cases (for this behavior we can write a new operator also).SortExec
when input ordering satisfy a prefix of the desired ordering.Describe the solution you'd like
No response
Describe alternatives you've considered
This should be a new operator or current
SortExec
can be extended to behave this way.However, I do think that extending current
SortExec
to behave this way is better option because:SortExec
and newPartialSortExec
)Additional context
See discussion for more background.
The text was updated successfully, but these errors were encountered: