Cycles in the rel graph are difficult to avoid. See
<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.
> 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
> 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
> 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
> 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.