[
https://issues.apache.org/jira/browse/CALCITE-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088895#comment-17088895
]
Botong Huang commented on CALCITE-3927:
---------------------------------------
The unit test gives an example of what can happen in real case, where
PhysSingleSubsetRule is a physical rule that has an operand matching for
RelSubset. When two RelSets having none identical physical traits get merged
(e.g. PHYS_CALLING_CONVENTION3 that is in the new RelSet but not in the
original RelSet), the RelSubset with the new physical trait that gets merged in
will never trigger the rule match again, but it should.
> RelSubset is not fired for rule when set gets merged
> ----------------------------------------------------
>
> Key: CALCITE-3927
> URL: https://issues.apache.org/jira/browse/CALCITE-3927
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In VolcanoPlanner, when set gets merged, planner fires rules again for
> RelNodes in both sets, but not for RelSubset. We might miss something because
> of this.
> If all the logical transformation rules and physical implementation rules are
> separated out in different stage and physical rules don't do logical work, we
> might be OK. But the reality is that all the things are mixed together at the
> moment.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
