zhuqi-lucas opened a new pull request, #22521: URL: https://github.com/apache/datafusion/pull/22521
## Which issue does this PR close? Closes #22520. ## Rationale for this change `ensure_distribution` in `datafusion/physical-optimizer/src/ensure_requirements/enforce_distribution.rs` unconditionally calls `plan.with_new_children(children_plans)` after collecting the (possibly redistributed) children, even when none of those children were actually replaced. For nodes like `ProjectionExec`, that path runs through `try_new` and recomputes the schema, equivalence properties, and output ordering — pure overhead when the input Arcs are byte-identical. Profiling a real workload dominated by point queries (deep `ProjectionExec` stack, no join / aggregate / unmet ordering) showed `ProjectionExec::with_new_children` as the single largest cost inside `ensure_distribution`: - `ensure_distribution` total: 2.87s of a 60s CPU sample - `ProjectionExec::with_new_children`: 1.94s (56% of the rule) - `OneOfExec::with_new_children`: 0.21s - `SortExec::with_new_children`: 0.11s - Other: 0.61s ## What changes are included in this PR? After collecting `children_plans`, compare each new child Arc with the original via `Arc::ptr_eq`. When every child is unchanged, reuse the existing `plan` Arc and skip `with_new_children`. The `UnionExec` to `InterleaveExec` special case still runs first because it intentionally produces a new node even when child Arcs are unchanged. ## Are these changes tested? Yes. The existing `enforce_distribution` suite passes unchanged (66/66): ``` cargo test --release -p datafusion --test core_integration -- physical_optimizer::enforce_distribution ``` The behavior is observable only as a CPU reduction; correctness is unchanged because reusing the unchanged Arc produces the same plan tree as `with_new_children(unchanged_children)` would have, just without the schema / ordering / equivalence recomputation. ## Are there any user-facing changes? No. Same plans, lower planning time. ## Micro-benchmark Plan shape: 30-deep `ProjectionExec` stack over a sorted parquet scan, 5000 iterations. - Without fix: 852.74 ms total, 170.55 us/call - With fix: 296.81 ms total, 59.36 us/call - ~2.87x speedup, -65% CPU per call -- 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]
