jayzhan211 commented on code in PR #25217: URL: https://github.com/apache/datafusion/pull/25217#discussion_r3998523741
########## datafusion/physical-plan/src/joins/hash_join/exec.rs: ########## Review Comment: `maintains_input_order` promises the probe (right) side's order for the join types that emit every row while scanning the probe side (Inner, Right, RightSemi, RightAnti, RightMark). That promise only becomes observable when the probe input is itself ordered: then, and only then, the join advertises an output ordering, and the planner may rely on it, for example by pushing an `ORDER BY` on a probe-side column below the join. The fallback is gated on exactly that. `HashJoinExec::execute` declines the fallback whenever `self.cache.output_ordering()` is `Some`, before any trigger is consulted. So every join that has promised an ordering keeps running as an in-memory hash join and preserves it, while a join with no advertised ordering has nothing to preserve and may switch to a merge freely. Checking the advertised ordering rather than `maintains_input_order` alone is deliberate: an ordered-preserving join type over an unordered input promises nothing, and declining there would lose the fallback for no benefit. Tests are added to increase more coverage -- 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]
