wangyum opened a new pull request, #12556:
URL: https://github.com/apache/gluten/pull/12556

   ## What changes are included in this PR?
   
   `ColumnarToColumnarExec` now propagates the child's `outputPartitioning` and 
`outputOrdering` instead of inheriting the defaults (`UnknownPartitioning` / 
`Nil`) from `SparkPlan` via `UnaryExecNode`.
   
   ```scala
   override def outputPartitioning: Partitioning = child.outputPartitioning
   
   override def outputOrdering: Seq[SortOrder] = child.outputOrdering
   ```
   
   plus the required `Partitioning` / `SortOrder` imports.
   
   ## Why are the changes needed?
   
   `ColumnarToColumnarExec` (in `gluten-core`) is the abstract base for 
operators that only reshape / resize / convert columnar batches without 
altering row distribution or order. Concrete subclasses include 
`VeloxResizeBatchesExec`, `ArrowColumnarToVeloxColumnarExec`, 
`OffloadArrowDataExec`, `LoadArrowDataExec`, and 
`GpuResizeBufferColumnarBatchExec`.
   
   Previously these wrappers reported `UnknownPartitioning(numColumns)` and 
`Nil` ordering, which misrepresents the physical layout. Consequences:
   
   - **Storage-partitioned joins / v2 bucketing** are not recognized when a 
batch-resize or format-convert node sits between a `BatchScanExec` (reporting 
`KeyGroupedPartitioning`) and the join, so the planner inserts a **redundant 
shuffle**, defeating the scan-reported partitioning.
   - **SortMergeJoin** plans lose the child's sort order across the wrapper and 
insert an **extra `Sort`**.
   - More generally, exchange reuse / AQE coalescing / ordering-based 
optimizations make suboptimal decisions whenever one of these wrappers is 
present.
   
   This mirrors how vanilla Spark's `ColumnarToRowExec` / `RowToColumnarExec` 
and Gluten's own `ColumnarInputAdapter` treat partitioning/ordering 
transparency. It applies to all supported Spark versions and all backends.
   
   Closes #12555.
   
   ## Does this PR introduce any user-facing change?
   
   No API change. Plans that previously inserted a redundant shuffle / sort 
around a columnar reshape can become more efficient.
   
   ## How was this patch tested?
   
   Existing unit tests (no behavioral change to data, only to plan shape); 
relied on the fact that the wrappers are data-transparent. Follow-up: a 
plan-shape assertion test for SPJ through a resize node can be added if 
reviewers want explicit coverage.
   
   ## Was this patch authored or co-authored using generative AI tooling?
   
   Yes.
   `Generated-by: opencode ebay-glm-5-2-fp8-chat`


-- 
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]

Reply via email to