perf: track BoundedWindowAggExec Linear-mode watermark once per stream - #24033
Merged
Dandandan merged 2 commits intoAug 4, 2026
Merged
Conversation
In Linear mode, rows arrive ordered on a prefix of the window's ORDER BY expressions, so each new row bounds every row that will arrive in the future, even for other partitions. We exploit this by using the last row to arrive in a batch to close window frames for all live partitions, not just the partition to which that row belongs. The most-recent-row-in-the-batch is conceptually per-batch state, but it was previously implemented as per-partition state: - update_partition_batch copied the last row of each incoming batch into every live partition's PartitionBatchState. - Each copy is ~(40 + 16 * n_cols) bytes (Option<RecordBatch> plus a Vec of ArrayRefs); for example, withn 100k live partitions over 10 columns, that is ~20MB of duplicate state. - Every partition visit re-evaluated the row's ORDER BY expressions. Instead, just store the row once. Rather than copying the row into every partition, we pass the row to window expression evaluation. This removes `most_recent_row` and its setter from `PartitionBatchState`, which is a breaking API change for datafusion-expr. We can also arrange to evaluate the ORDER BY once per batch instead of once per partition. This is a modest performance improvement and memory savings, but also a conceptual cleanup/refactor. Benchmark results (benches/bounded_window.rs): - linear 100 partitions: 44.4 ms -> 44.5 ms (within noise) - linear 10000 partitions: 203.3 ms -> 199.7 ms (-1.7%) - linear sparse 32768 partitions: 236.9 ms -> 224.5 ms (-5.2%) - linear rows 10000 partitions: 174.2 ms -> 169.4 ms (-2.4%) - linear multi 10000 partitions: 304.6 ms -> 295.7 ms (-3.0%) - sorted 10000 partitions: 34.2 ms -> 34.4 ms (within noise)
BoundedWindowAggExec Linear-mode watermark once per stream
|
Thank you for opening this pull request! Reviewer note: cargo-semver-checks reported the current version number is not SemVer-compatible with the changes in this pull request (compared against the base branch). Details |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #24033 +/- ##
==========================================
- Coverage 80.85% 80.85% -0.01%
==========================================
Files 1101 1101
Lines 374933 374941 +8
Branches 374933 374941 +8
==========================================
Hits 303166 303166
- Misses 53671 53677 +6
- Partials 18096 18098 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Dandandan
approved these changes
Aug 3, 2026
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
BoundedWindowAggExecinLinearmode is slow for many-partitions #23982Rationale for this change
In Linear mode, rows arrive ordered on a prefix of the window's ORDER BY expressions, so each new row bounds every row that will arrive in the future, even for other partitions. We exploit this by using the last row to arrive in a batch to close window frames for all live partitions, not just the partition to which that row belongs.
The most-recent-row-in-the-batch is conceptually per-batch state, but it was previously implemented as per-partition state:
update_partition_batchcopied the last row of each incoming batch into every live partition'sPartitionBatchState.Option<RecordBatch>plus aVecofArrayRefs); for example, withn 100k live partitions over 10 columns, that is ~20MB of duplicate state.Instead, just store the row once. Rather than copying the row into every partition, we pass the row to window expression evaluation. This removes
most_recent_rowand its setter fromPartitionBatchState, which is a breaking API change for datafusion-expr. We can also arrange to evaluate the ORDER BY once per batch instead of once per partition.This is a modest performance improvement and memory savings, but also a conceptual cleanup/refactor.
Benchmarks: (using #24032)
What changes are included in this PR?
WindowEvalContextparameter toaggregate_evaluate_statefulPartitionBatchState::most_recent_rowand its setter; instead pass row viaWindowEvalContextAre these changes tested?
Yes, covered by existing tests.
Are there any user-facing changes?
Yes, API change to
datafusion-expr.