jayzhan211 commented on code in PR #26734:
URL: https://github.com/apache/datafusion/pull/26734#discussion_r4389451108
##########
datafusion/physical-plan/src/aggregates/hash_stream.rs:
##########
@@ -838,7 +842,33 @@ impl FinalHashAggregateStream {
// The table hands over its groups as they are materialized and
// reports a size of 0 once it reaches `Done`, so this releases the
// reservation before the final batch goes downstream.
- self.reservation.try_resize(hash_table.memory_size())?;
+ match self.reservation.try_resize(hash_table.memory_size()) {
+ Ok(()) => {}
+ // The materialized output is bigger than the table was. Write
+ // it to disk and stream it back instead of failing the query.
+ Err(e @ DataFusionError::ResourcesExhausted(_)) => {
+ let spill_context = spill_context.ok_or_else(|| e.context(
Review Comment:
I ran the reproducer from #26701 on this branch, and it now returns the same
rows as the unlimited run, with one spill. One gap: no test reaches this
spill-disabled branch, so the new "cannot spill its output" error could revert
unnoticed (`without_spilling_returns_refusal` refuses earlier, in
`consume_input`). Could you add a run to `output_materialization_refused` in
this PR? The table still fits there without the spill headroom, so it should
hit this branch:
```rs
let run = Case {
spill_enabled: false,
..padded(AggregateMode::Final)
}
.run()
.await?;
assert_eq!(run.spill_count(), 0);
assert!(run.snapshot.contains("cannot spill its output"));
```
##########
datafusion/physical-plan/tests/cases/aggregate_memory_call_sequence.rs:
##########
@@ -610,15 +609,16 @@ async fn output_materialization_refused() -> Result<()> {
};
let run = padded(AggregateMode::Final).run().await?;
- assert_eq!(run.spill_count(), 0);
+ assert_eq!(run.spill_count(), 1);
+ assert_eq!(run.output_batch_rows, vec![64; 4]);
Review Comment:
Optional: this checks the row counts after the spill round-trip, but not the
values. Comparing the output with an unlimited run, as the `string_agg`
reproducer in #26701 does with `batches_to_sort_string`, would also catch a
reordered column or a dropped slice in `spill_output`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]