Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add basic multi-partition
GroupBy
support to cuDF-Polars #17503base: branch-25.04
Are you sure you want to change the base?
Add basic multi-partition
GroupBy
support to cuDF-Polars #17503Changes from 3 commits
f0964a6
1329cf1
11a03f8
a9fa486
b1224a0
385f03a
8956215
70b29b2
3f04eca
e090de5
24b88f2
161a53b
69f6336
22cebeb
45ac8ec
f5205bd
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by elementwise keys? It's certainly not the case that we always group on columns. But I think it is the case that the group keys (if expressions) are trivially elementwise (e.g.
a + b
as a key is fine, buta.unique()
ora.sort()
is not)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. I'm being extra cautious by requiring the keys to be
Col
. This comment is essentially asking: "can we drop this check altogether? ie. Will the keys always be element-wise?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe so, yes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened pola-rs/polars#20152 as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to think about this (and possibly reorganise what we're doing in the single-partition case) to make this easier to handle.
For example, I think it is going to do the wrong thing for
.agg(a.max() + b.min())
I think what you're trying to do here is turn a
GroupBy(df, keys, aggs)
intoReduce(LocalGroupBy(df, keys, agg_exprs), keys, transformed_aggs)
And what does this look like, I think once we've determined the "leaf" aggregations we're performing (e.g.
col.max()
) then we must concat and combine to get the full leaf aggregations, followed by evaluation of the column expressions that produce the final result.So suppose we have determined what the leaf aggs are, and then what the post-aggregation expressions are, for a single-partition this is effectively
Select(GroupBy(df, keys, leaf_aggs), keys, post_agg_exprs)
wherepost_agg_exprs
are all guaranteed elementwise (for now).thought: Would it be easier for you here if the
GroupBy
IR nodes really only held aggregation expressions that are "leaf" aggregations (with the post-processing done in aSelect
)?I think it would, because then the transform becomes something like:
Where
groupbycombine
emits the tree-reduction tasks with the post aggregations.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure the answer is "yes" :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick follow-up: I totally agree that we probably want to revise the upstream
GroupBy
design to make the decomposition here a bit simpler. With that said, I don't think we are doing anything "wrong" here. Rather, the code would just need to become unnecessarily messy if we wanted to do much more than "simple" mean/count/min/max aggregations.We won't do the "wrong" thing here - We will just raise an error. E.g.: