Dandandan commented on code in PR #3530:
URL: https://github.com/apache/arrow-datafusion/pull/3530#discussion_r975240832
##########
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:
`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.
The remaining optimization I think is tweaking `SortPreservingMergeStream`
to only maintain `fetch` records in the heap instead of all `fetch` top records
for each batch in the partition as mentioned here
https://github.com/apache/arrow-datafusion/issues/3516#issuecomment-1250807415.
After this I think we have a full TopK implementation that only needs to keep
n number of rows in memory (per partition).
I would like to do this in a separate PR.
--
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]
