Thanks Julian for the quick response. I'll follow CALCITE-794.

And I got more details:

rels:
0 = {LogicalFilter@3579}
"rel#10:LogicalFilter.NONE.[](input=rel#9:Subset#0.ENUMERABLE.[],condition=>($0,
3))"
1 = {LogicalProject@3584}
"rel#12:LogicalProject.NONE.[](input=rel#11:Subset#1.NONE.[],ID=$0,NAME=$1,ADDR=$2)"
2 = {StormProjectRel@3554}
"rel#21:StormProjectRel.STORM_LOGICAL.[](input=rel#20:Subset#1.STORM_LOGICAL.[],ID=$0,NAME=$1,ADDR=$2)"
3 = {LogicalCalc@3585}
"rel#22:LogicalCalc.NONE.[[]](input=rel#11:Subset#1.NONE.[],expr#0..2={inputs},ID=$t0,NAME=$t1,ADDR=$t2)"
4 = {TridentStormFilterRel@3569}
"rel#24:TridentStormFilterRel.STORM_LOGICAL.[](input=rel#23:Subset#0.STORM_LOGICAL.[],condition=>($0,
3))"
5 = {TridentStormCalcRel@3586}
"rel#25:TridentStormCalcRel.STORM_LOGICAL.[[]](input=rel#20:Subset#1.STORM_LOGICAL.[],expr#0..2={inputs},ID=$t0,NAME=$t1,ADDR=$t2)"
6 = {LogicalCalc@3587}
"rel#26:LogicalCalc.NONE.[[]](input=rel#9:Subset#0.ENUMERABLE.[],expr#0..2={inputs},expr#3=3,expr#4=>($t0,
$t3),ID=$t0,NAME=$t1,ADDR=$t2,$condition=$t4)"
7 = {TridentStormCalcRel@3588}
"rel#27:TridentStormCalcRel.STORM_LOGICAL.[[]](input=rel#23:Subset#0.STORM_LOGICAL.[],expr#0..2={inputs},expr#3=3,expr#4=>($t0,
$t3),ID=$t0,NAME=$t1,ADDR=$t2,$condition=$t4)"

best:
rel#24:TridentStormFilterRel.STORM_LOGICAL.[](input=rel#23:Subset#0.STORM_LOGICAL.[],condition=>($0,
3))

Relsub.toString() just picks the first one, which might not be same as
Volcano planner selects. (Please correct me if I'm wrong.)
If it is, I think it's not intuitive though they're logically equivalent,
because when user requests explain user wants to see actual (selected)
plan. Is it possible to provide the actual plan? If 'best' representing the
selection, why not just printing out the best?

Btw, I filed an issue: https://issues.apache.org/jira/browse/CALCITE-1438
I'm not clearly understanding on your solution for now, but if you haven't
had time to resolve after I followed up CALCITE-794, I'll try to make a
patch.

Thanks,
Jungtaek Lim (HeartSaVioR)

2016년 10월 14일 (금) 오전 7:30, Julian Hyde <jh...@apache.org>님이 작성:

> Cycles in the rel graph are difficult to avoid. See
> https://issues.apache.org/jira/browse/CALCITE-794 <
> https://issues.apache.org/jira/browse/CALCITE-794> for details. They are
> not fatal for optimization (as long as the nodes in the graph have positive
> cost, the cheapest plan (which is basically a path through the graph) will
> not be a cycle) but they are still best avoided. Adding simplifications in
> RelBuilder eliminates some common causes of cycles.
>
> I agree that RelOptUtil.toString must not give StackOverflowError. Can you
> please log a bug for this?
>
> The solution is probably straightforward: maintain a set of “active” nodes
> in the RelWriter created by RelOptUtil.toString.
>
> Julian
>
>
> > On Oct 13, 2016, at 3:17 PM, Jungtaek Lim <kabh...@gmail.com> wrote:
> >
> > Hi devs,
> >
> > While I'm converting Storm SQL to convert Calcite logical to Storm's own
> > logical, I found one of Storm's unit test is failing. I put
> > RelOptUtil.toString() on every tests, and broken test is throwing
> > StackOverflowError.
> >
> > When it was also failing from IDEA, I dug it more, and found that one of
> > rels in Relsub has parent Relsub as 'input' (Relsub and Project).
> > Fortunately it was not selected to 'best', but Relsub print out first
> > occurence of rel which match the trait, and unfortunately it's first one.
> >
> > Query is really simple, INSERT INTO BAR SELECT ID, NAME, ADDR FROM FOO
> > WHERE ID > 3. It was not making an issue when Storm SQL uses Calcite
> > logical.
> >
> > I'm not sure making cross reference is a problem, but IMO throwing
> > StackOverflowError in explain is a major problem.
> >
> > I picked the workaround by printing out 'best' if it's available (not
> null)
> > instead of first occurrence of rel which match the trait.
> >
> > Does it make sense? If then I'll come up with filing an issue and
> following
> > pull request. I don't have an idea to reproduce so might not have test on
> > it.
> >
> > Thanks,
> > Jungtaek Lim (HeartSaVioR)
> >
> > ps. Below is the ruleset I'm experimenting with. Please correct if I'm
> > using conflict rules together, or any odd things.
> >
> > SortRemoveRule.INSTANCE,
> > FilterToCalcRule.INSTANCE,
> > ProjectToCalcRule.INSTANCE,
> > FilterCalcMergeRule.INSTANCE,
> > ProjectCalcMergeRule.INSTANCE,
> > CalcMergeRule.INSTANCE,
> > PruneEmptyRules.FILTER_INSTANCE,
> > PruneEmptyRules.PROJECT_INSTANCE,
> > PruneEmptyRules.UNION_INSTANCE,
> > ProjectFilterTransposeRule.INSTANCE,
> > FilterProjectTransposeRule.INSTANCE,
> > ProjectRemoveRule.INSTANCE,
> > ReduceExpressionsRule.FILTER_INSTANCE,
> > ReduceExpressionsRule.PROJECT_INSTANCE,
> > ReduceExpressionsRule.CALC_INSTANCE,
> > UnionEliminatorRule.INSTANCE,
> > StormScanRule.INSTANCE,
> > StormFilterRule.INSTANCE,
> > StormProjectRule.INSTANCE,
> > StormAggregateRule.INSTANCE,
> > StormJoinRule.INSTANCE,
> > StormModifyRule.INSTANCE,
> > StormCalcRule.INSTANCE
>
>

Reply via email to