[CALCITE-2456] VolcanoRuleCall#match works incorrectly for unordered child operand

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.17.0
• Fix Version/s: 1.20.0
• Component/s: core
• Labels: pull-request-available

Environment

Test on Calcite master branch as of 8/7/2018 with Java 8.

• Assignee: Unassigned
• Reporter: Zuozhi Wang
• Created: 08/Aug/18 09:39
• Updated: 24/Jun/19 15:02
• Resolved: 09/Apr/19 16:17

Description

Bug Description:

This bug occurs when there'a rule matching a Union operator with an unordered operand: 

`operand(Union.class, unordered(operand(RelTypeB.class, any())))`,

with an plan tree that the operand to match is not the first input to the union:

LogicalUnion
  RelTypeA
  RelTypeB

The expected behavior is that this plan tree should fire the match, because `unordered` means matching any child of the union operator.

The bug is that the tree is not matched as expected, either matching in descending order (rule is triggered from LogicalUnion) or in ascending order (rule is triggered by adding another node equivalent to RelTypeB).

How to reproduce:

See the test cases in https://github.com/apache/calcite/pull/784

Bug cause:

The cause of this issue is that VolcanoRuleCall doesn't handle `unordered` child operand at all. It uses `operand.ordinalInParent` to check if the matched RelNode matches the operand's ordinal(position) in parent's inputs. The value of `ordinalInParent` is always `0` in this case, requires the matched RelNode to also be the first input.

However, that only makes sense when child policy is `some`, which strictly requires to match in order. For child policy `unordered`, it should match regardless of the position of RelNode in the inputs.

Bug fix:

This bug can be fixed with changes to function`VolcanoRuleCall#matchRecurse`:
See https://github.com/apache/calcite/pull/784

 

Thanks.

Issue Links

• blocks: CALCITE-2575 Release Calcite 1.18.0
• links to: GitHub Pull Request #784