[
https://issues.apache.org/jira/browse/CALCITE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979925#comment-16979925
]
Jin Xing edited comment on CALCITE-3505 at 11/22/19 7:18 AM:
-------------------------------------------------------------
Currently, Calcite checks whether to skip a rule match by [link|#L520]]. But it
only checks the cycle along the path of rule operands. In this case the cycle
exists but longer than the path of operands.
[https://github.com/apache/calcite/pull/855] refines and checks cycle to
include input of the operands. But I think it might be not enough. Think that
there are three RelSubsets in the cycle and the operands length is 2.
Intuitively I think there are two approaches to resolve this issue.
# Ban the cycles. I will go with [~julianhyde] in CALCITE-2223 and aggree that
we will lose a lot by this approach. Actually cycle can happen very easily –
RelSubset which contains an identity Project will reference itself.
# Remember the matching history – – if a group of nodes was matched before by
a certain rule, there's no need to do the matching again.
was (Author: [email protected]):
Currently, Calcite checks whether to skip a rule match by
[link|[https://github.com/apache/calcite/blob/295ab13e8338bdd0e0c29e051907371c9b2929aa/core/src/main/java/org/apache/calcite/plan/volcano/RuleQueue.java#L520]].
But it only checks the cycle along the path of rule operands. In this case the
cycle exists but longer than the path of operands.
[https://github.com/apache/calcite/pull/855] refines and checks cycle to
include input of the operands. But I think it might be not enough. Think that
there are three RelSubsets in the cycle and the operands length is 2.
Intuitively I think there are two approaches to resolve this issue.
# Ban the cycles. I will go with [~julianhyde] in CALCITE-2223 that we will
lose a lot by this approach. Actually cycle can happen very easily – RelSubset
which contains an identity Project will reference itself.
# Remember the matching history – – if a group of nodes was matched before by
a certain rule, there's no need to do the matching again.
> Infinite matching of FilterProjectTransposeRule causes stackoverflow
> --------------------------------------------------------------------
>
> Key: CALCITE-3505
> URL: https://issues.apache.org/jira/browse/CALCITE-3505
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jin Xing
> Priority: Major
> Attachments: graphviz.svg
>
>
> Run ScannableTableTest#testProjectableFilterableTableJoin with minor change
> to reproduce
> {code:java}
> @Test public void testProjectableFilterableTableJoin() throws Exception {
> final StringBuilder buf = new StringBuilder();
> final String explain = "PLAN="
> + "EnumerableHashJoin(condition=[=($0, $3)], joinType=[inner])\n"
> + " EnumerableInterpreter\n"
> + " BindableTableScan(table=[[s, b1]], filters=[[=($0, 10)]])\n"
> + " EnumerableInterpreter\n"
> + " BindableTableScan(table=[[s, b2]], filters=[[=($0, 10)]])";
> CalciteAssert.that()
> .with(
> newSchema("s",
> Pair.of("b1", new BeatlesProjectableFilterableTable(buf,
> true)),
> Pair.of("b2", new BeatlesProjectableFilterableTable(buf,
> true))))
> .query("select * from \"s\".\"b1\", \"s\".\"b2\" "
> + "where \"s\".\"b1\".\"i\" = 10 and \"s\".\"b2\".\"i\" =
> 10 "
> + "and \"s\".\"b1\".\"i\" = \"s\".\"b2\".\"i\"")
> .withHook(Hook.PLANNER, (Consumer<RelOptPlanner>) planner -> {
> planner.removeRule(EnumerableRules.ENUMERABLE_MERGE_JOIN_RULE);
> })
> .explainContains(explain);
> }
> {code}
> This test has nothing to do with ENUMERABLE_MERGE_JOIN_RULE, but if we
> disable it with planner hook, stackoverflow happens;
> I debugged and found that FilterProjectTransposeRule is matched infinitely
> but not sure the root cause.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
