[
https://issues.apache.org/jira/browse/CALCITE-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019875#comment-17019875
]
Vladimir Sitnikov commented on CALCITE-3744:
--------------------------------------------
{quote}RelNode #4's input RelSubset changed, its digest also changed. So we
can't detect the duplication and will re-apply rulematch 43 twice{quote}
Cache invalidation and naming things collided here :)
Frankly speaking, I came across that code multiple times, and I never cared to
look at what it actually was doing.
Well, I'm not sure it is always duplication.
Subset merging can alter metadata properties, so the same rule invocation might
result in different outcomes depending on the metadata.
In other words, I agree it makes no sense to keep multiple 12 12 12 in the
queue (so using ID for keys in the queue is good), however, it might still make
sense to execute 12 multiple times during the planning process in case the
environment changed (e.g. subsets merged).
> 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
> Time Spent: 1h
> 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)
