[
https://issues.apache.org/jira/browse/CALCITE-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007940#comment-17007940
]
Haisheng Yuan commented on CALCITE-3668:
----------------------------------------
{quote}It won't if LogicalFilter uses Subset#{convention=NONE} {quote}
Well, you are right, it matches all relnodes satisfying its traitset. Then
would it make sense to return all the traitsets with same convention for
RelSubset?
{quote}You can still use operand(RelSubset.class) and use subset.set.subsets in
your own rule code.{quote}
Do you think it is a good practice to expose subset.set.subsets? They are not
public, can't be accessed through rule.
{quote}On the other hand, if you make the planner use subset.set.subsets, then
it would produce unrealistic matches that can't be resolved in the rule
code.{quote}
What do you mean? It has been there for 10 years or so, no one reports any
issue with it.
> VolcanoPlanner doesn't match all the RelSubSet in matchRecursive
> ----------------------------------------------------------------
>
> Key: CALCITE-3668
> URL: https://issues.apache.org/jira/browse/CALCITE-3668
> Project: Calcite
> Issue Type: Bug
> Reporter: Haisheng Yuan
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If I have a rule to match pattern with Filter-RelSubset, VolcanoPlanner only
> matches 1 RelSubset in the RelSet, instead of all the subsets.
> {code:java}
> if (operand.getMatchedClass() == RelSubset.class) {
> // If the rule wants the whole subset, we just provide it
> successors = ImmutableList.of(subset);
> } else {
> successors = subset.getRelList();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
