You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Haisheng Yuan (Jira)" <ji...@apache.org> on 2020/01/23 21:45:00 UTC

[jira] [Resolved] (CALCITE-3744) Duplicate RuleMatches when RelSet gets merged

     [ https://issues.apache.org/jira/browse/CALCITE-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Haisheng Yuan resolved CALCITE-3744.
------------------------------------
    Fix Version/s: 1.22.0
       Resolution: Fixed

Fixed in https://github.com/apache/calcite/commit/0196bb67a5255b7b0f9e297c74742c4d7203403d.

> Duplicate RuleMatches when RelSet gets merged
> ---------------------------------------------
>
>                 Key: CALCITE-3744
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3744
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: Haisheng Yuan
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.22.0
>
>          Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Some times RelSet can get merged. e.g.
> Each number represet Rel id, and they are in different RelSet.
> {code:java}
>  1            4
>    \          /
>      2      / 
>        \    /
>          3
> {code}
> Assume in the rulequeue, we have rule match with name of  12, 23, 43. For simplicity, omit the rule name, first digit represent the parent RelNode, second represent the child.
> If after some rule, we merged the set of 3 into the set of 2, and RelNode 4's input is replaced by RelSubset of 2. We will retrigger rules and try to add rulematch 12, 42, 43 into rule queue.
> 12 will be filtered out, because there is duplicate in the RuleMatch names set. But for 43, it now has different rulematch digest with previous match, because RelNode #4's input RelSubset changed, its digest also changed. So we can't detect the duplication and will re-apply rulematch 43 twice.
> Although we try to recompute rulematch's digest when popMatch(), but it seems too late. 
> I think in RuleMatch digest, just using relnode's id should suffice. And we don't need to call recomputeDigest when popMatch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)