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 performance of SortedRangeSet discrete union #21992

Closed
sopel39 opened this issue May 16, 2024 · 5 comments · Fixed by #22073
Closed

Improve performance of SortedRangeSet discrete union #21992

sopel39 opened this issue May 16, 2024 · 5 comments · Fixed by #22073
Assignees
Labels

Comments

@sopel39
Copy link
Member

sopel39 commented May 16, 2024

When all SortedRangeSets are discrete, then performance of SortedRangeSet#union could de improved greatly. Improving union would reduce DF collection latency and reduce coordinator CPU usage (DF are unioned on coordinator).

This is follow up from: #21657

@sopel39 sopel39 added the good first issue Good for newcomers label May 16, 2024
@sopel39
Copy link
Member Author

sopel39 commented May 16, 2024

cc @Dith3r @raunaqmorarka

@chenjian2664
Copy link
Contributor

Hi, I want to take this, could you give me some hits about this? @sopel39

@Dith3r
Copy link
Member

Dith3r commented May 20, 2024

@chenjian2664
Add special case for unions where all SortedRangeSet are discrete, similar to linked PR. The main point is to avoid copy of single value and use range copy of raw values as much as possible.

@chenjian2664
Copy link
Contributor

@Dith3r Thanks for the guidance

@sopel39
Copy link
Member Author

sopel39 commented May 20, 2024

The other thing is when you are dealing with discrete set you can just use single comparison to compare "ranges" (as in https://github.com/trinodb/trino/pull/21657/files#diff-a3ede16a05943d869ba6d7b8821761bc3ed3d23915bb0b3bf8bac363b7038deaR585).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

3 participants