comphead commented on code in PR #26242:
URL: https://github.com/apache/datafusion/pull/26242#discussion_r4339030296
##########
datafusion/physical-plan/src/sorts/sort.rs:
##########
@@ -728,6 +784,87 @@ impl ExternalSorter {
.build()
}
+ /// Sort runs concurrently, preserving their order for the merge's
equal-key ties.
+ async fn prepare_sort_runs(
+ &mut self,
+ runs: Vec<RecordBatch>,
+ concurrency: &SortConcurrency,
+ ) -> Result<Vec<SendableRecordBatchStream>> {
+ let run_count = runs.len();
+ let (sizes, shared_input_size) = self.sort_run_sizes(&runs)?;
+ let shared_input =
+ shared_input_size.map(|size|
Arc::new(self.reservation.split(size)));
+ let jobs =
+ runs.into_iter()
+ .zip(sizes)
+ .enumerate()
+ .map(move |(index, (batch, size))| {
+ let reservation = self.reservation.split(size);
+ let sort = self.sort_run(batch, reservation,
shared_input.clone())?;
+ let permits = Arc::clone(&concurrency.permits);
+ Ok::<_, DataFusionError>(async move {
+ let stream = Self::prepare_sort_run(sort,
permits).await?;
+ Ok((index, stream))
+ })
+ });
+ // Ordered buffering would keep completed runs behind a slow earlier
run,
+ // filling the window and preventing new jobs from starting.
+ let jobs = futures::stream::iter(jobs)
+ .try_buffer_unordered(concurrency.per_partition_limit);
+ Self::collect_prepared_runs(run_count, jobs).await
+ }
+
+ /// Restore input order because the merge uses it to break equal-key ties.
Review Comment:
Small wording point. The merge does not preserve run order for equal keys,
for two reasons.
- Each run is sorted with `lexsort_to_indices`, which arrow documents as an
unstable sort.
- `StreamingMergeBuilder` defaults to `enable_round_robin_tie_breaker: true`
and `in_mem_sort_stream` does not override it, so equal keys are interleaved
across runs by poll count.
What the reassembly does guarantee is deterministic output regardless of job
completion order, which is still worth keeping. I would phrase this comment,
the one on `prepare_sort_runs` and the description that way. This also corrects
my earlier comment on `spill_tests.rs`, which framed it as tie stability. The
new tests are fine as determinism checks.
--
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]
