You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Ruben Q L (Jira)" <ji...@apache.org> on 2020/04/15 13:25:00 UTC

[jira] [Comment Edited] (CALCITE-3926) CannotPlanException when an empty LogicalValues requires a certain collation

    [ https://issues.apache.org/jira/browse/CALCITE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17084078#comment-17084078 ] 

Ruben Q L edited comment on CALCITE-3926 at 4/15/20, 1:24 PM:
--------------------------------------------------------------

{{Note that: if we remove PruneEmptyRules.SORT_INSTANCE from the planner, the plan execution succeeds:}}
{code:java}
  @Test void testEmptyValues() {
    tester(false, new JdbcTest.HrSchema())
        .query("?")
       // removing PruneEmptyRules.SORT_INSTANCE: test ok; otherwise test fails
        .withHook(Hook.PLANNER, (Consumer<RelOptPlanner>) planner -> planner.removeRule(PruneEmptyRules.SORT_INSTANCE))
        .withRel(
            builder -> builder
                .scan("s", "depts").as("d")
                .filter(
                    builder.literal(false))
                .sort(
                    builder.field("name"),
                    builder.field("deptno"))
                .build())
        .returnsUnordered("");
  }
{code}


was (Author: rubenql):
Note that: if we remove PruneEmptyRules.SORT_INSTANCE from the planner, the plan execution succeeds:
{code}
  @Test void testEmptyValues() {
    tester(false, new JdbcTest.HrSchema())
        .query("?")
       // removing PruneEmptyRules.SORT_INSTANCE: test ok; otherwise test fails
        .withHook(Hook.PLANNER, (Consumer<RelOptPlanner>) planner -> planner.removeRule(PruneEmptyRules.SORT_INSTANCE))
        .withRel(
            builder -> builder
                .scan("s", "depts").as("d")
                .filter(
                    builder.literal(false))
                .sort(
                    builder.field("name"),
                    builder.field("deptno"))
                .build())
        .returnsUnordered("");
  }
{code}

> CannotPlanException when an empty LogicalValues requires a certain collation
> ----------------------------------------------------------------------------
>
>                 Key: CALCITE-3926
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3926
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.23.0
>            Reporter: Ruben Q L
>            Priority: Blocker
>
> The issue can be reproduced with the following test (in RelBuilderTest.java):
> {code:java}
>   @Test void testEmptyValues() throws Exception {
>     final RelBuilder builder = RelBuilder.create(config().build());
>     final RelNode root =
>         builder
>             .scan("DEPT")
>             .filter(builder.literal(false)) // generates an empty LogicalValues
>             .sort(
>                 builder.field("DNAME"),
>                 builder.field("DEPTNO"))
>             .build();
>     try (PreparedStatement preparedStatement = RelRunners.run(root)) {
>       final String s = CalciteAssert.toString(preparedStatement.executeQuery());
>       final String result = "";
>       assertThat(s, is(result));
>     }
>   }
> {code}
> The test fails with the following message:
> {code:java}
> Caused by: org.apache.calcite.plan.RelOptPlanner$CannotPlanException: There are not enough rules to produce a node with desired properties: convention=ENUMERABLE, sort=[1, 0].
> Missing conversion is LogicalValues[convention: NONE -> ENUMERABLE, sort: [[0, 1, 2], [1, 2], [2]] -> [1, 0]]
> There is 1 empty subset: rel#14:Subset#0.ENUMERABLE.[1, 0], the relevant part of the original plan is as follows
> 1:LogicalValues(tuples=[[]])
> {code}
> The issue seems to be caused by the empty values: Scan + Filter(false) => LogicalValues({}).
>  This empty LogicalValues has as collation (in case of 3 fields): [[0, 1, 2], [1, 2], [2]]; and in the plan we are requesting as sort collation [1, 0].
> It seems the issue was somehow introduced by CALCITE-3886
>  [https://github.com/apache/calcite/commit/08f4a9889728f94903ff424ed9c20d940b821af5]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)