[ 
https://issues.apache.org/jira/browse/CALCITE-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858053#comment-16858053
 ] 

Botong Huang commented on CALCITE-3118:
---------------------------------------

Sure, supposedly this rule should only match once, with left child operand == 
leftPhy (PHYS, label = a) and right child operand == rightPhy (PHYS_2, label == 
b). 

However, without the fix, when rightPhy gets generated, it triggers two match 
attempts. The first one is expected as above. In the second one, rightPhy 
(PHYS_2, label == b) matches the left child operand, then we attempt to match 
the PhyBiRel as parent operand. 

Supposedly this parent should not match, because rightPhy is PhyBiRel's second 
child, but rightPhy's matched left child operand is parent operand's first 
child. Because of the bug, it didn't skip as expected and still proceed with 
the matching. After parent is matched, then it attempt to match the right child 
operand, and again matched the rightPhy (PHYS_2, label == b), as expected 
because it is PhyBiRel's second child. Overall as a result, both child operand 
end up matching the same RelNode rightPhy (PHYS_2, label == b). 

Hope this is clearer now. 

> VolcanoRuleCall match parent child ordinal not properly checked
> ---------------------------------------------------------------
>
>                 Key: CALCITE-3118
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3118
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Botong Huang
>            Priority: Major
>              Labels: pull-request-available
>
> In VolcanoRuleCall.matchRecurse(), when ascending (child operand is matched, 
> looking for parent operand match), we want to check that the matched parent 
> indeed has the previously matched child RelNode as a child with the expected 
> ordinal. However, there is a bug in this check. As a result, some incorrect 
> parent is not skipped as expected and matched incorrectly. See unit test 
> included in PR for a case that triggers this bug, where the same RelNode get 
> matched for two operands at the same time. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to