Is your feature request related to a problem? Please describe.
Auron supports residual conditions for native inner sort-merge and shuffled hash joins through #2197, and native inner broadcast hash joins through #2438.
Support remains limited for non-inner joins and broadcast nested loop joins with conditions, causing these queries to fall back to Spark. Extending support requires evaluating the condition before finalizing matched and unmatched rows, including outer, semi, anti, and existence join results.
The existing inner-join implementation also materializes candidate columns before filtering them. This can create unnecessary copying and allocation when duplicate keys produce many candidate pairs and the residual condition rejects most of them.
Describe the solution you'd like
Extend the existing native CPU join-condition support through five incremental changes:
- Add shared condition-evaluation utilities with column remapping, projection handling, and bounded candidate evaluation.
- Extend native sort-merge joins to support residual conditions for outer, semi, anti, and existence joins.
- Extend native broadcast hash joins to support residual conditions for additional supported join types and build orientations.
- Enable the extended support in native shuffled hash joins, including forced sort-merge-to-shuffled-hash conversion.
- Support conditions in native broadcast nested loop joins without equality keys, while retaining build-side restrictions required for correctness.
Preserve the existing condition serialization, planning interfaces, and configuration switch. Rework native candidate evaluation and match tracking to preserve SQL semantics and reduce unnecessary materialization.
There are several sub-issues:
Completing these issues will broaden native join-condition support and is expected to improve performance, especially for joins with many candidate pairs and selective residual predicates.
Is your feature request related to a problem? Please describe.
Auron supports residual conditions for native inner sort-merge and shuffled hash joins through #2197, and native inner broadcast hash joins through #2438.
Support remains limited for non-inner joins and broadcast nested loop joins with conditions, causing these queries to fall back to Spark. Extending support requires evaluating the condition before finalizing matched and unmatched rows, including outer, semi, anti, and existence join results.
The existing inner-join implementation also materializes candidate columns before filtering them. This can create unnecessary copying and allocation when duplicate keys produce many candidate pairs and the residual condition rejects most of them.
Describe the solution you'd like
Extend the existing native CPU join-condition support through five incremental changes:
Preserve the existing condition serialization, planning interfaces, and configuration switch. Rework native candidate evaluation and match tracking to preserve SQL semantics and reduce unnecessary materialization.
There are several sub-issues:
Completing these issues will broaden native join-condition support and is expected to improve performance, especially for joins with many candidate pairs and selective residual predicates.