[
https://issues.apache.org/jira/browse/CALCITE-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421268#comment-17421268
]
Ruben Q L commented on CALCITE-4809:
------------------------------------
Can you provide a unit test?
[MergeJoin implementation has a
prerrequisite|https://github.com/apache/calcite/blob/219e41eab20533f02d41238d1ebc617cc813b9a2/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L2208]:
inputs sorted in ascending order with nulls last. I have the impression that
in your example this is not respected: after the left t1xt2 there should have
been a sort by t2.id nulls last, which will lead to 4,4 being processed before
3,null; which would lead to the correct result.
> Mixed merge join result is incomplete
> --------------------------------------
>
> Key: CALCITE-4809
> URL: https://issues.apache.org/jira/browse/CALCITE-4809
> Project: Calcite
> Issue Type: Bug
> Components: linq4j
> Affects Versions: 1.26.0
> Reporter: super486
> Priority: Major
>
> The result of mixed merge join is incomplete. The merge join relies on the
> row data of the two tables to be sorted by the join field, but if the left
> table itself is a left join, nulls may appear due to mismatches, causing the
> entire join to end early。
> EG：
> t1 left join t2 on t1.id=t2.id join t3 on t2.id=t3.id;
> t1 rows: 1,2,3,4
> t2 rows: 1,2,4
> t3 rows: 1.2.3.4
> final result is:1,2. but 4 is lost;
> when MergeJoinEnumerator left (t1xt2) come to: 3,null, right (t3) is 3,
> the null <3 cause left advance finish wrong
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
