[
https://issues.apache.org/jira/browse/CALCITE-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025118#comment-15025118
]
Julian Hyde commented on CALCITE-794:
-------------------------------------
[~jcamachorodriguez], Regarding AggregateJoinTransposeRule and cycles, note
that that I spent some time working with [~ashutoshc] yesterday. Since metadata
calls were more expensive than the rule, if you generated a call stack Calcite
would probably be evaluating metadata; but the real problem was the cycle in
the Hep program. We solved the loop by adding
{{HepProgramBuilder.addMatchLimit(1)}} to a program.
Regarding actual cycles - which show up as StackOverflowError - I did quite a
bit of work on this issue but did not manage to complete it. You can see my
work in https://github.com/julianhyde/calcite/tree/794-cycles. The key
innovation is that before making a metadata call you create an instance of
RelMetadataQuery, and that has sufficient state to detect re-entrant calls.
Once you are "inside" the metadata system - e.g. if you are implementing a
provider for row count that needs to get selectivity - you use the
RelMetadataQuery object that was passed in.
This would be a big API change, but just about acceptable for a minor release,
in my opinion.
I can't remember what work was left to do. I think you should checkout
794-cycles and see which tests still fail. It wouldn't be very hard to rebase
onto current master.
> Detect cycles when computing statistics
> ---------------------------------------
>
> Key: CALCITE-794
> URL: https://issues.apache.org/jira/browse/CALCITE-794
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Fix For: next
>
>
> The graph of RelNodes is allowed to be cyclic. This causes problems when
> evaluating certain metadata, for example RelMetataQuery.areColumnsUnique.
> While computing the value for RelNode r, it might recurse through say a
> Project and hit r again. This causes a stack overflow.
> We solve this by adding a map or set of active RelNodes. The map is stored
> within RelMetadataQuery, which can now be instantiated, and its methods are
> no longer static. The first call should instantiate a RelMetadataQuery, but
> all subsequent calls for metadata (perhaps several kinds of metadata) will
> use the same RelMetadataQuery instance, hence the same map.
> Also add a RelMetadataQuery argument to the static "handler" methods in
> RelMdColumnUniqueness and similar classes.
> This is a breaking change for people who have written a metadata handler, and
> might be subtle to detect, because the methods are invoked via reflection.
> For code that is just using RelMetadataQuery methods, the change is still
> breaking, but the break points and remedy will be obvious: the methods are no
> longer static, so they need to change RelMetadataQuery.foo() to
> RelMetadataQuery.instance().foo().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
