[
https://issues.apache.org/jira/browse/CALCITE-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367533#comment-14367533
]
Jinfeng Ni commented on CALCITE-628:
------------------------------------
The change you made to VolcanoPlaner should fix this Assertion problem, since
Frameworks.planner.transform() or RelOptRule.convert() will come down to the
code in VolcanoPlanner. In fact, with the change in VolcanoPlanner, the
simplify() call in Prepare.getDesiredRootTraitSet() seems also un-necessary.
{code}
return rel2.set.getOrCreateSubset(rel.getCluster(), toTraits.simplify());
{code}
However, after looking at RelTraitSets.simplify(), I'm not sure whether the
change in VolcanoPlanner is the best solution.
{code}
x = x.replace(i,
compositeTrait.size() == 0
? trait.getTraitDef().getDefault()
: compositeTrait.trait(0));
{code}
The code essentially says that given a compositeTrait, the first trait will be
honored. That means, if the caller pass RelCollation of [a, b], [c] as the
target toTraits, VolcanoPlanner will "silently" call simplify() and use the
first trait [a,b] as the target trait. One could argues why not the second
trait? I understand RelCompositeTrait requires strict ordering of multiple
traits. In the case of RelCollation, there is no clear reason why [a,b] is
better than [c].
In that sense, I feel it might be better to enforce the "simple" requirement in
the caller, adding assertion either in Planner.transform(), or
RelOptRule.convert(), in stead of calling simplify() in VolcanoPlanner. It
seems not making too much sense to ask the planner for a RelNode with
RelCollation of [a, b] and [c]. If that's what the caller wants, he can do the
transform or convert multiple times, each with a different simple trait.
> Calcite hit Assertion Error when calling Frameworks.planner or
> RelOptRule.convert(), if the target trait is composite
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-628
> URL: https://issues.apache.org/jira/browse/CALCITE-628
> Project: Calcite
> Issue Type: Bug
> Reporter: Jinfeng Ni
> Assignee: Julian Hyde
>
> CALCITE-88 introduces the concept of RelCompositeTrait. As such, Calcite
> seems to require that each new RelSubSet should only have simple trait, in
> stead of composite traits. If that condition is not meet, an assertion will
> be thrown.
> However, when we use Frameworks.planner to call transform(), or use
> RelOptRule to call convert() method, there is no guarantee that the target
> traits are simple. If the target traits happened to be composite, then
> Calcite will hit Assertion at RelSubset.java:108.
> There seems to be two options to fix this Assertion and ensure RelSubset only
> have simple traitsets :
> 1) Follow the way Prepare.optimize(), and call simplify() for the target
> traitset, in both PlannerImpl.transform() or RelOptRule.convert().
> 2) Each callers of transform(), or convert() method should make sure the
> target traits are simple.
> The patch I'm going to submit uses the 1st option, using the same logic in
> Prepare.optimize().
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
