sunchao commented on code in PR #25053:
URL: https://github.com/apache/datafusion/pull/25053#discussion_r4039115200
##########
datafusion/physical-expr/src/equivalence/properties/joins.rs:
##########
@@ -107,6 +95,124 @@ pub fn join_equivalence_properties(
Ok(result)
}
+/// Append build orderings only when equal probe ordering values identify at
most
+/// one build row. The suffix is then constant within each probe ordering
group,
+/// even if probe rows repeat. For an outer join preserving the probe side, all
+/// join keys must be fixed within the group, and the caller must rule out
filters,
+/// so the group cannot mix matched build rows with NULL-extended rows.
+fn unique_build_join_orderings(
+ probe: &EquivalenceProperties,
+ build: &EquivalenceProperties,
+ on: &[(PhysicalExprRef, PhysicalExprRef)],
+ probe_side: JoinSide,
+ preserves_unmatched_probe: bool,
+ null_equality: NullEquality,
+) -> Result<OrderingEquivalenceClass> {
+ if build.constraints().is_empty() || build.oeq_class().is_empty() {
+ return Ok(OrderingEquivalenceClass::default());
Review Comment:
[P2] Preserve suffix ordering when the probe prefix is unique
The build-constraint requirement overlooks a safe case: when the probe
ordering contains its primary key, each ordering group contains one probe row,
so ordered build matches cannot restart within that group. With a
PK-constrained probe emitting one row then remaining pending, and four ordered
duplicate build matches, ORDER BY probe.k, build.v LIMIT 1 returns immediately
on current base a2b8093. Here, both HashJoin and SortMergeJoin gain
PartialSortExec and time out waiting for more input. Finite controls return
correctly. Include probe-side uniqueness as an alternative proof.
##########
datafusion/physical-expr/src/equivalence/properties/joins.rs:
##########
@@ -107,6 +95,124 @@ pub fn join_equivalence_properties(
Ok(result)
}
+/// Append build orderings only when equal probe ordering values identify at
most
+/// one build row. The suffix is then constant within each probe ordering
group,
+/// even if probe rows repeat. For an outer join preserving the probe side, all
+/// join keys must be fixed within the group, and the caller must rule out
filters,
+/// so the group cannot mix matched build rows with NULL-extended rows.
+fn unique_build_join_orderings(
+ probe: &EquivalenceProperties,
+ build: &EquivalenceProperties,
+ on: &[(PhysicalExprRef, PhysicalExprRef)],
+ probe_side: JoinSide,
+ preserves_unmatched_probe: bool,
+ null_equality: NullEquality,
+) -> Result<OrderingEquivalenceClass> {
+ if build.constraints().is_empty() || build.oeq_class().is_empty() {
+ return Ok(OrderingEquivalenceClass::default());
+ }
+ let on = on
+ .iter()
+ .map(|(left, right)| {
+ let (probe_key, build_key) = match probe_side {
+ JoinSide::Left => (left, right),
+ JoinSide::Right => (right, left),
+ JoinSide::None => unreachable!(),
+ };
+ (Arc::clone(probe_key), Arc::clone(build_key))
+ })
+ .collect::<Vec<_>>();
+ let mut valid_orderings = Vec::new();
+ for ordering in probe.oeq_class().iter() {
+ // Within a group of equal ordering values, these expressions are
+ // constant. Keep this assumption local to the ordering proof.
+ let mut group = probe.eq_group().clone();
+ for sort in ordering {
+ let expr = probe.eq_group().normalize_expr(Arc::clone(&sort.expr));
+ group.add_constant(ConstExpr::from(expr));
Review Comment:
[P2] Consider combined probe orderings for composite keys
Checking each stored ordering separately misses a valid combined prefix. A
probe independently ordered by [k] and [v] is also ordered by [k,v], which can
determine a build PRIMARY KEY(k,v). Neither singleton passes this proof, so
ORDER BY probe.k, probe.v, build.payload LIMIT 1 gains PartialSortExec and
stalls when the probe remains pending. The identical native plan returns
immediately on current base a2b8093; finite controls pass on both revisions.
Also evaluate valid concatenated prefixes, retaining the suffix only for the
prefix actually proved.
--
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]
