[
https://issues.apache.org/jira/browse/CALCITE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16759024#comment-16759024
]
Volodymyr Vysotskyi commented on CALCITE-2223:
----------------------------------------------
If I understand the intention of PR-1019 correctly, it will significantly
reduce matching rules by allowing applying rules to the rel nodes with concrete
convention either specified explicitly or deduced from passed RelBuilderFactory.
>From the logs for failing
>{{TestExampleQueries.testMultipleComparisonWithSingleValueSubQuery}} test I
>see a lot of the following entries:
{{Rel {} does not match rule {} since the relation does not match implicit
traits {}}}
Most of the rules accept {{RelFactories.LOGICAL_BUILDER}}, so they will create
logical rel nodes, and at the logical planning stage, everything works fine.
But the same rules which are used for the logical stage are also applied at the
physical stage to allow optimizing the plan after applying physical rules.
Not sure that the case {{LogicalProject(FilterPrel(...))}} is applicable for
the rules, but there are converters, which may convert {{LogicalProject}} to
{{DrillProjectRel}} and then to {{ProjectPrel}}, so the rule may be applied at
least to {{ProjectPrel(FilterPrel(...))}}
But with the changes made in the PR it becomes impossible. I think this is the
reason why these tests fail. In particular, I think the problem here is with
joins reordering. One of the rules (or more) wasn't applied, and perhaps nested
loop join which by default allowed only for scalar subqueries was on top of the
regular loin.
> ProjectMergeRule is infinitely matched when is applied after
> ProjectReduceExpressionsRule
> -----------------------------------------------------------------------------------------
>
> Key: CALCITE-2223
> URL: https://issues.apache.org/jira/browse/CALCITE-2223
> Project: Calcite
> Issue Type: Bug
> Reporter: Volodymyr Vysotskyi
> Assignee: Julian Hyde
> Priority: Critical
> Attachments:
> TestLimitWithExchanges_testPushLimitPastUnionExchange.png, heap_overview.png,
> provenance_contents.png
>
>
> For queries like this:
> {code:sql}
> select t1.f from (select cast(f as int) f, f from (select cast(f as int) f
> from (values('1')) t(f))) as t1
> {code}
> OOM is thrown when {{ProjectMergeRule}} is applied before applying
> {{ProjectReduceExpressionsRule}} in VolcanoPlanner.
> A simple test to reproduce this issue (in {{RelOptRulesTest}}):
> {code:java}
> @Test public void testOomProjectMergeRule() {
> RelBuilder relBuilder =
> RelBuilder.create(RelBuilderTest.config().build());
> RelNode relNode = relBuilder
> .values(new String[]{"f"}, "1")
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f"))
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f0"),
> relBuilder.alias(relBuilder.field(0), "f"))
> .project(
> relBuilder.alias(relBuilder.field(0), "f"))
> .build();
> RelOptPlanner planner = relNode.getCluster().getPlanner();
> RuleSet ruleSet =
> RuleSets.ofList(
> ReduceExpressionsRule.PROJECT_INSTANCE,
> new ProjectMergeRuleWithLongerName(),
> EnumerableRules.ENUMERABLE_PROJECT_RULE,
> EnumerableRules.ENUMERABLE_VALUES_RULE);
> Program program = Programs.of(ruleSet);
> RelTraitSet toTraits =
> relNode.getCluster().traitSet()
> .replace(0, EnumerableConvention.INSTANCE);
> RelNode output = program.run(planner, relNode, toTraits,
> ImmutableList.<RelOptMaterialization>of(),
> ImmutableList.<RelOptLattice>of());
> // check for output
> }
> /**
> * ProjectMergeRule inheritor which has
> * class name greater than ProjectReduceExpressionsRule class name
> (String.compareTo()).
> *
> * It is needed for RuleQueue.popMatch() method
> * to apply this rule before ProjectReduceExpressionsRule.
> */
> private static class ProjectMergeRuleWithLongerName extends
> ProjectMergeRule {
> public ProjectMergeRuleWithLongerName() {
> super(true, RelFactories.LOGICAL_BUILDER);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
