alamb commented on code in PR #3530:
URL: https://github.com/apache/arrow-datafusion/pull/3530#discussion_r975362476
##########
datafusion/core/src/physical_plan/sorts/sort.rs:
##########
@@ -816,14 +831,14 @@ fn sort_batch(
batch: RecordBatch,
schema: SchemaRef,
expr: &[PhysicalSortExpr],
+ fetch: Option<usize>,
) -> ArrowResult<BatchWithSortArray> {
- // TODO: pushup the limit expression to sort
let sort_columns = expr
.iter()
.map(|e| e.evaluate_to_sort_column(&batch))
.collect::<Result<Vec<SortColumn>>>()?;
- let indices = lexsort_to_indices(&sort_columns, None)?;
+ let indices = lexsort_to_indices(&sort_columns, fetch)?;
Review Comment:
A separate PR is a great idea 👍
> lexsort_to_indices already returns only fetch indices per batch, this is
used to take that nr. of indices per batch, throwing away the rest of the rows.
Right, the point I was trying to make is that there are 2 calls to
`lexsort_to_indices` in sort.rs. I think this PR only pushed `fetch` to one of
them. The second is
https://github.com/apache/arrow-datafusion/blob/3a9e0d0/datafusion/core/src/physical_plan/sorts/sort.rs#L826
and I think it is correct to push `fetch` there too
I was thinking if we applied `fetch` to the second call, we could get close
to the same effect without changing `SortPreservingMergeStream`.
* After this PR, sort buffers `num_input_batches * input_batch_size` rows.
* Adding `fetch` to the other call to `lexsort_to_indices` would would
buffer `num_input_batches * limit` rows
* Extending `SortPreservingMergeStream` would allow us to buffer only
`limit` rows.
So clearly extending `SortPreservingMergeStream` is optimal in terms of rows
buffered, but it likely requires a bit more effort.
--
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]
