[jira] [Commented] (CALCITE-1438) RelOptUtils.toString() throws StackOverflowError when RelSubset and input makes cycle

["Jungtaek Lim (JIRA)" <ji...@apache.org>]

    [ 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)