metesynnada commented on PR #4439:
URL:
https://github.com/apache/arrow-datafusion/pull/4439#issuecomment-1333481206
Let's consider more general use cases of `output_ordering()`. In
`DefaultPhysicalPlanner.create_initial_plan()`, we should be able to depend on
`output_ordering()` and `output_partitioning()` regardless of the optimization
step. Let’s think we have `AExec` and `BExec`.
```
AExec
⬇️
BExec
```
where
```rust
impl ExecutionPlan for AExec {
fn output_ordering(&self) -> Option<&[PhysicalSortExpr]> {
self.input.output_ordering()
}
}
```
If I call `AExec.output_ordering()` in `DefaultPhysicalPlanner`, it will
gives `BExec`’s output order. I can make decisions depending on it in planner
phase. To make this plan “runnable”, we should not add new operators to the
between `AExec` and `BExec` outside of the planner. If `AExec` requires an
input ordering, this should be decided inside the planner and add to the
operator chain to make `output_ordering()` API work. Currently, these API’s are
broken since we did not add a `SortExec` inside the planner.
--
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: github-unsubscr...@arrow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
