Uh oh!
There was an error while loading. Please reload this page.
refactor(hash-aggr): Forward port the soft limit optimization to the new hash aggregation impl - #22824
Merged
Merged
Conversation
ariel-miculas
approved these changes
Jun 8, 2026
alamb
approved these changes
Jun 8, 2026
alamb
left a comment
Contributor
There was a problem hiding this comment.
Looks good to me -- thank you @2010YOUY01 and @ariel-miculas
| }; | ||
| #[derive(Debug)] | ||
| struct AggregateRuntimeMetric { |
Contributor
There was a problem hiding this comment.
A few comments here (explaining what the limit and output row fields are in particualr) I think would help this test be easier to read
ContributorAuthor
There was a problem hiding this comment.
Thank you, makes sense to me. Addressed in f54bf19
| } | ||
| #[tokio::test] | ||
| async fn limited_distinct_aggregate_uses_migrated_hash_streams() -> Result<()> { |
Contributor
There was a problem hiding this comment.
I would recommend a different term that "migrated" as once the migration is complete it will not be relevant anympre
Perhaps something like "limited_distinct_aggregate_uses_partial_hash_stream" would be more future proof
2010YOUY01
commented
Jun 9, 2026
ContributorAuthor
By estimation, there are around 5 PRs to go for this refactor. |
martin-g
approved these changes
Jun 9, 2026
Uh oh!
There was an error while loading. Please reload this page.
…egation.rs Co-authored-by: Martin Grigorov <martin-g@users.noreply.github.com>
Uh oh!
There was an error while loading. Please reload this page.
16 tasks
AdamGS pushed a commit
to AdamGS/arrow-datafusion
that referenced
this pull request
Jun 11, 2026
…new hash aggregation impl (apache#22824) ## Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. For example `Closesapache#123` indicates that this PR will close issue apache#123. --> - part of apache#22710 ## Rationale for this change <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> Part of rewriting hash aggregation into several dedicated streams. In the first step apache#22729, `PartialHashAggregateStream` and `FinalHashAggregateStream` has been split from the old `GroupsHashAggregateStream`, but both stream only have basic implementation, no optimizations and extra features like spilling. \* it's incremental migration, so old impl won't change, we plan to delete it once migration is finished This PR forward ports the below optimization to the new implementation: - apache#8038 The optimizer part don't have to move, ported changes are only inside aggregate operator. ## What changes are included in this PR? <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> Extends `PartialHashAggregateStream` and `FinalHashAggregateStream` to apply the optimization. See code comment at `datafusion/physical-plan/src/aggregates/hash_aggregate.rs` for the background. ## Are these changes tested? <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 2. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? --> Yes, the original test in apache#8038 is only at `ExecutionPlan` level, they're still passing after the change. This PR added new test coverage: check `explain analyze` to ensure the implementation actually respects this soft limit at runtime. ## Are there any user-facing changes? <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. --> <!-- If there are any breaking changes to public APIs, please add the `api change` label. --> --------- Co-authored-by: Martin Grigorov <martin-g@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Which issue does this PR close?
Rationale for this change
Part of rewriting hash aggregation into several dedicated streams.
In the first step #22729,
PartialHashAggregateStreamandFinalHashAggregateStreamhas been split from the oldGroupsHashAggregateStream, but both stream only have basic implementation, no optimizations and extra features like spilling.* it's incremental migration, so old impl won't change, we plan to delete it once migration is finished
This PR forward ports the below optimization to the new implementation:
The optimizer part don't have to move, ported changes are only inside aggregate operator.
What changes are included in this PR?
Extends
PartialHashAggregateStreamandFinalHashAggregateStreamto apply the optimization. See code comment atdatafusion/physical-plan/src/aggregates/hash_aggregate.rsfor the background.Are these changes tested?
Yes, the original test in #8038 is only at
ExecutionPlanlevel, they're still passing after the change.This PR added new test coverage: check
explain analyzeto ensure the implementation actually respects this soft limit at runtime.Are there any user-facing changes?