refactor(hash-aggr): migrate ordered single aggregation - #24259
refactor(hash-aggr): migrate ordered single aggregation#242592010YOUY01 wants to merge 1 commit into
Conversation
2010YOUY01
changed the title
| } | ||
|
|
||
| /// Merges every sorted run and finalizes it through the fully ordered path. | ||
| fn into_replay_stream( |
There was a problem hiding this comment.
This step is mostly similar to the spilling paths of other aggregation modes. We should extract the common logic later.
There was a problem hiding this comment.
maybe worth a ticket to track
| &mut self, | ||
| evaluated_batch: &EvaluatedAggregateBatch, | ||
| is_final: bool, | ||
| aggregate_fn: AggregateBatchFn, |
There was a problem hiding this comment.
here is the key change for this file, just a clean-up to make it easier to be reused by different aggregation modes.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #24259 +/- ##
==========================================
- Coverage 81.06% 81.00% -0.06%
==========================================
Files 1107 1108 +1
Lines 382191 384599 +2408
Branches 382191 384599 +2408
==========================================
+ Hits 309805 311533 +1728
- Misses 54083 54709 +626
- Partials 18303 18357 +54 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
alamb
left a comment
alamb
left a comment
There was a problem hiding this comment.
looks great to me -- thank you @2010YOUY01
| )?)); | ||
| } | ||
|
|
||
| if self.should_use_ordered_single_aggregate_stream(context) { |
There was a problem hiding this comment.
FWIW while I like the explicit name of these methods I do wonder if the difference between them might be clearer if there was one giant match statement (rather than a bunch of if ... chains)
There was a problem hiding this comment.
For example the only difference between should_use_single_hash_stream and should_use_ordered_single_aggregate_stream seems to be the condition
&& self.input_order_mode != InputOrderMode::Linear🤔
| /// [`StreamType::OrderedPartialAggregate`], and | ||
| /// [`StreamType::OrderedFinalAggregate`] | ||
| /// [`StreamType::OrderedFinalAggregate`], and |
There was a problem hiding this comment.
Doc nit: this list now has a double "and" ("… and OrderedFinalAggregate, and OrderedSingleAggregate").
| /// [`StreamType::OrderedPartialAggregate`], and | |
| /// [`StreamType::OrderedFinalAggregate`] | |
| /// [`StreamType::OrderedFinalAggregate`], and | |
| /// [`StreamType::OrderedPartialAggregate`], | |
| /// [`StreamType::OrderedFinalAggregate`], and |
| } | ||
|
|
||
| /// Merges every sorted run and finalizes it through the fully ordered path. | ||
| fn into_replay_stream( |
There was a problem hiding this comment.
maybe worth a ticket to track
3 participants
Which issue does this PR close?
part of #22710
Rationale for this change
Migrate ordered single aggregation path.
For the background of the refactor, see EPIC issue for details
For the overview of the refactored path, see comments at the top of
datafusion/physical-plan/src/aggregates/ordered_single_stream.rsWhat changes are included in this PR?
datafusion/physical-plan/src/aggregates/mod.rs: physical planning changes that route the applicable execution to the 'ordered-single-aggregate` pathdatafusion/physical-plan/src/aggregates/ordered_single_stream.rs: main implementation. Overview is at the comments forOrderedSingleAggregateStream, and the entry point for execution state machine is atpoll_next()Are these changes tested?
Existing tests. I have verified the test line coverage from
llvm-covAre there any user-facing changes?
No