lyne7-sc commented on code in PR #25053:
URL: https://github.com/apache/datafusion/pull/25053#discussion_r3974966525
##########
datafusion/physical-expr/src/equivalence/properties/joins.rs:
##########
@@ -49,56 +49,17 @@ pub fn join_equivalence_properties(
..
} = right;
match maintains_input_order {
- [true, false] => {
- // In this special case, right side ordering can be prefixed with
- // the left side ordering.
- if matches!(join_type, JoinType::Inner | JoinType::Left)
- && probe_side == Some(JoinSide::Left)
- {
- updated_right_ordering_equivalence_class(
- &mut right_oeq_class,
- join_type,
- left_size,
- )?;
-
- // Right side ordering equivalence properties should be
prepended
- // with those of the left side while constructing output
ordering
- // equivalence properties since stream side is the left side.
- //
- // For example, if the right side ordering equivalences contain
- // `b ASC`, and the left side ordering equivalences contain `a
ASC`,
- // then we should add `a ASC, b ASC` to the ordering
equivalences
- // of the join output.
- let out_oeq_class =
left_oeq_class.join_suffix(&right_oeq_class);
- result.add_orderings(out_oeq_class);
- } else {
- result.add_orderings(left_oeq_class);
- }
- }
+ // Only the maintained side's ordering is guaranteed. With duplicate
+ // probe keys, the other side's matches repeat for each probe row, so
+ // its ordering cannot be appended as a suffix.
+ [true, false] => result.add_orderings(left_oeq_class),
[false, true] => {
updated_right_ordering_equivalence_class(
&mut right_oeq_class,
join_type,
left_size,
)?;
- // In this special case, left side ordering can be prefixed with
- // the right side ordering.
- if matches!(join_type, JoinType::Inner | JoinType::Right)
- && probe_side == Some(JoinSide::Right)
- {
- // Left side ordering equivalence properties should be
prepended
- // with those of the right side while constructing output
ordering
- // equivalence properties since stream side is the right side.
- //
- // For example, if the left side ordering equivalences contain
- // `a ASC`, and the right side ordering equivalences contain
`b ASC`,
- // then we should add `b ASC, a ASC` to the ordering
equivalences
- // of the join output.
- let out_oeq_class =
right_oeq_class.join_suffix(&left_oeq_class);
- result.add_orderings(out_oeq_class);
- } else {
- result.add_orderings(right_oeq_class);
- }
+ result.add_orderings(right_oeq_class);
Review Comment:
Thanks for pointing this out. The inner join case can indeed retain the
ordering with the right uniqueness guarantees. I also noticed that
probe-preserving outer joins can retain it when the maintained ordering
determines all join keys and there is no additional join filter. I’ve updated
the ordering inference for these cases and added tests verifying that LIMIT
returns even when the unbounded probe stream remains pending within the same
key group.
--
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]
