Skip to content

Support RangePartitioning with native shuffle #458

Closed

Description

@andygrove

What is the problem the feature request solves?

We do not currently support RangePartitioning with native shuffle.

Adding this support would allow us to use native shuffle for more queries, including queries where there is a global sort.

Describe the potential solution

No response

Additional context

No response

Activity

  1. viirya commented on May 22, 2024

    @viirya
    Member

    Since the early development of Comet shuffle, this is one item on to do list. After we finish columnar shuffle which has higher coverage and support main partitioning types, we turn our focus to other more urgent items. Because we want to increase query coverage as much as possible. Currently we can run TPC-H queries mostly native, seems we can go back to look at this as it can give us more performance gain on shuffle (because native shuffle is faster than columnar shuffle).

  2. viirya commented on May 22, 2024

    @viirya
    Member

    I will work on this after finishing HashJoin build right support.

  3. self-assigned this
    on May 22, 2024
  4. added this to the 0.4.0 milestone on Oct 3, 2024
  5. self-assigned this
    on Oct 3, 2024
  6. andygrove commented on Oct 3, 2024

    @andygrove
    MemberAuthor

    This would help with TPC-H performance, so I plan on taking a look at this issue soon

  7. removed this from the 0.4.0 milestone on Oct 25, 2024
  8. jinwenjie123 commented on Mar 28, 2025

    @jinwenjie123

    Hi @andygrove
    May I ask why we decide not support RangePartitioning ? and will it be supported in the near future ?
    Thanks

  9. andygrove commented on Mar 29, 2025

    @andygrove
    MemberAuthor

    Hi @andygrove
    May I ask why we decide not support RangePartitioning ? and will it be supported in the near future ?
    Thanks

    We didn't decide not to support it.

    It just hasn't been implemented yet because it is more complex than other partitioning schemes. It would be great if someone could submit a PR to add support for this. It could really help with benchmark results and performance overall.

  10. andygrove commented on Mar 29, 2025

    @andygrove
    MemberAuthor

    I discussed this feature with @mbutrovich recently and he may have additional thoughts on this topic.

  11. viirya commented on Mar 29, 2025

    @viirya
    Member

    The implementation issue or difference for RangePartitioning other than other partitioning like HashPartitioning, is that it involves some sampling operations that perform with RDD in Spark. That's said Comet lib at each executor cannot determine the sampling results separately like we did for general query execution.

  12. andygrove commented on Jan 30, 2026

    @andygrove
    MemberAuthor

    Implemented in #1862, with follow-up fixes in #1907, #2258, and #2716. Closing.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions