[
https://issues.apache.org/jira/browse/IGNITE-12984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17115904#comment-17115904
]
Andrey Mashenkov commented on IGNITE-12984:
-------------------------------------------
I've found a bug on H2 side and unfortunately, we can't make correct fix on
Ignite side.
The only option is to disable unicast at all.
This bug affects OUTER JOINs if there is a cascade of 3+ joined tables in a
query.
Some asserts can be broken (or wrong results can be got, if assertions are
disables) in DistributedLookupBatch
when results of first join contains both: rows from 1-st table that have pair
on 2-nd tablem and rows that are not from 1-st table that has no pair (join wih
'null' row)
and they all are interleaved.
I has no idea why DistributedLookupBatch tries to make join using BFS instead
of DFS algorithm for joining as DFS looks more naturally here.
I've tried to fix this using DFS approach and it works fine, but as I wrote it
can't be fixes in Ignite as DistributedLookupBatch is a part of H2.
> Distributed join incorrectly processed when batched:unicast on primary key is
> used
> ----------------------------------------------------------------------------------
>
> Key: IGNITE-12984
> URL: https://issues.apache.org/jira/browse/IGNITE-12984
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 2.8
> Reporter: Ilya Kasnacheev
> Assignee: Taras Ledkov
> Priority: Major
> Attachments: Issue_with_Distributed_joins.pdf, forDistributedJoins.sql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Please see attached SQL script and userlist discussion.
> Summary :
> CASE-1 Results: Correct and as expected
> {code}
> SELECT
> __Z0.ID AS __C0_0,
> __Z0.NAME AS __C0_1,
> __Z1.BLOOD_GROUP AS __C0_2,
> __Z2.UNIVERSAL_DONOR AS __C0_3
> FROM PUBLIC.PERSON__Z0
> /* PUBLIC.PERSON_NAME_ASC_IDX_proxy */
> LEFT OUTER JOIN PUBLIC.MEDICAL_INFO __Z1
> /* batched:broadcast PUBLIC.MEDICAL_INFO_NAME_ASC_IDX: NAME = __Z0.NAME */
> ON __Z0.NAME = __Z1.NAME
> LEFT OUTER JOIN PUBLIC.BLOOD_GROUP_INFO_PJ __Z2
> /* batched:broadcast PUBLIC.BLOOD_GROUP_INFO_PJ_BLOOD_GROUP_ASC_IDX:
> BLOOD_GROUP =
> __Z1.BLOOD_GROUP */
> ON __Z1.BLOOD_GROUP = __Z2.BLOOD_GROUP
> {code}
> {code}
> Summary :
> CASE-2 Results: In-correct
> SELECT
> __Z0.ID AS __C0_0,
> __Z0.NAME AS __C0_1,
> __Z1.BLOOD_GROUP AS __C0_2,
> __Z2.UNIVERSAL_DONOR AS __C0_3
> FROM PUBLIC.PERSON __Z0
> /* PUBLIC.PERSON_ID_ASC_IDX_proxy */
> LEFT OUTER JOIN PUBLIC.MEDICAL_INFO __Z1
> /* batched:broadcast PUBLIC.MEDICAL_INFO_NAME_ASC_IDX: NAME = __Z0.NAME */
> ON __Z0.NAME = __Z1.NAME
> LEFT OUTER JOIN PUBLIC.BLOOD_GROUP_INFO_P __Z2
> /* batched:unicast PUBLIC._key_PK_proxy: BLOOD_GROUP = __Z1.BLOOD_GROUP */
> ON __Z1.BLOOD_GROUP = __Z2.BLOOD_GROUP
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
