SubhamSinghal commented on code in PR #25467: URL: https://github.com/apache/datafusion/pull/25467#discussion_r4052516026
########## datafusion/sqllogictest/test_files/pwmj.slt: ########## @@ -503,6 +503,148 @@ ORDER BY 1 NULLS FIRST; NULL 1 +# ------------------------------------------------------------------ +# LeftMark via PiecewiseMergeJoin +# ------------------------------------------------------------------ + +# `LeftMark` has no SQL syntax of its own -- it is produced by decorrelating an EXISTS/IN +# subquery that appears inside a disjunction, since the outer filter then needs the +# subquery's match result (the `mark`) as a value rather than as a row filter. Same data and +# correlation as the plain-EXISTS `LeftSemi` case above: no `t1.t1_id` is over 100, so the +# `OR` degenerates to the mark alone and the result is identical -- 11 is the one row whose +# mark is `false` and is correctly excluded. +query I +SELECT t1.t1_id +FROM join_t1 t1 +WHERE t1.t1_id > 100 OR EXISTS (SELECT 1 FROM join_t2 t2 WHERE t1.t1_id > t2.t2_id) +ORDER BY 1; +---- +22 +33 +44 + +query TT +EXPLAIN +SELECT t1.t1_id +FROM join_t1 t1 +WHERE t1.t1_id > 100 OR EXISTS (SELECT 1 FROM join_t2 t2 WHERE t1.t1_id > t2.t2_id) +ORDER BY 1; +---- +logical_plan +01)Sort: t1.t1_id ASC NULLS LAST +02)--Projection: t1.t1_id +03)----Filter: t1.t1_id > Int32(100) OR __correlated_sq_1.mark +04)------LeftMark Join: Filter: t1.t1_id > __correlated_sq_1.t2_id +05)--------SubqueryAlias: t1 +06)----------TableScan: join_t1 projection=[t1_id] +07)--------SubqueryAlias: __correlated_sq_1 +08)----------SubqueryAlias: t2 +09)------------TableScan: join_t2 projection=[t2_id] +physical_plan +01)SortPreservingMergeExec: [t1_id@0 ASC NULLS LAST] +02)--SortExec: expr=[t1_id@0 ASC NULLS LAST], preserve_partitioning=[true] +03)----FilterExec: t1_id@0 > 100 OR mark@1, projection=[t1_id@0] +04)------RepartitionExec: partitioning=RoundRobinBatch(4), input_partitions=1 +05)--------PiecewiseMergeJoin: operator=Gt, join_type=LeftMark, on=(t1_id > t2_id) +06)----------SortExec: expr=[t1_id@0 ASC], preserve_partitioning=[false] +07)------------DataSourceExec: partitions=1, partition_sizes=[1] +08)----------DataSourceExec: partitions=1, partition_sizes=[1] + +# `PiecewiseMergeJoinExec::swap_inputs` is unimplemented (`todo!()`), and the physical +# optimizer's statistics-driven swap subrule (`join_selection.rs`) only ever downcasts to +# `HashJoinExec`/`CrossJoinExec`/`NestedLoopJoinExec` -- it does not consider +# `PiecewiseMergeJoinExec` at all. So unlike the equijoin case in `mark_join_matrix.slt` +# (where a size-skewed `LeftMark` on `HashJoinExec` gets swapped to `RightMark` with inputs +# flipped), a size-skewed range mark join through PWMJ has nothing to trigger that swap and +# must stay `LeftMark` regardless of which side is bigger. This pins that: if +# `swap_inputs` is ever implemented and wired in, this plan changing to `RightMark` is the +# signal to add real `RightMark` coverage here rather than an accidental behavior change. +statement ok +CREATE TABLE pwmj_mark_swap_l(k INT) AS VALUES (1); Review Comment: Addressed in 8885ca1914c081f0f5c97984d7248fcf5c18cd7d -- 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]
