[
https://issues.apache.org/jira/browse/CALCITE-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15579337#comment-15579337
]
Jungtaek Lim commented on CALCITE-1438:
---------------------------------------
http://mail-archives.apache.org/mod_mbox/calcite-dev/201610.mbox/%3CCAF5108hJPjnBWB7ffcD_URjgd9Jj%2BKP%3DAcgd0e4Eppstun7QLw%40mail.gmail.com%3E
What I have learnt from above mail thread (mainly Q&As) is that the tree
retrieved from VolcanoPlanner.findBestExp() shouldn't have RelSubset. Storm SQL
(which is what I'm working on) has some tests and only this case has RelSubset
in actual plan.
I could make a patch for just not throwing StackOverflowError but throwing
other exception like HepPlanner.assertNoCycles() does. But I'd wish
VolcanoPlanner can handle cycles (by getting rid of cases) and finally replace
RelSubset with best case as non-cycle plan does now. Please note that I use the
word 'wish' since I don't know how much it is hard to achieve. Might be better
to file a new issue if it is eventually possible and makes sense.
> RelOptUtils.toString() throws StackOverflowError when RelSubset and input
> makes cycle
> -------------------------------------------------------------------------------------
>
> Key: CALCITE-1438
> URL: https://issues.apache.org/jira/browse/CALCITE-1438
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jungtaek Lim
> Assignee: Julian Hyde
> Priority: Critical
>
> I 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. I didn't see this when I directly uses Calcite logical.
> rels:
> {code}
> 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)"
> {code}
> best:
> {code}
> rel#24:TridentStormFilterRel.STORM_LOGICAL.[](input=rel#23:Subset#0.STORM_LOGICAL.[],condition=>($0,
> 3))
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
