[jira] [Commented] (CALCITE-3409) Add an interface in MaterializedViewSubstitutionVisitor to allow registering UnifyRule
[
https://issues.apache.org/jira/browse/CALCITE-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418425#comment-17418425
]
xzh_dz commented on CALCITE-3409:
-
[~zabetak] [~jcamachorodriguez]
thanks for review..
I update the code and avoid changing the `{{RelOptPlanner`}} APIs. Using
`CustomMaterializedViewRecognitionRuleTest` to test custom materialized view
recognition rules.And overload `RelOptMaterializations#useMaterializedViews()`
method ,It can be compatible with the original implementation.Please review the
[latest
commit|[https://github.com/apache/calcite/pull/2094].|https://github.com/apache/calcite/pull/2094].Thanks]
thanks again.
> Add an interface in MaterializedViewSubstitutionVisitor to allow registering
> UnifyRule
> --
>
> Key: CALCITE-3409
> URL: https://issues.apache.org/jira/browse/CALCITE-3409
> Project: Calcite
> Issue Type: Improvement
>Reporter: Jin Xing
>Assignee: Jin Xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> In current code of MaterializedViewSubstitutionVisitor, all matching rules
> are internal defined. The existing rules support the most popular scenarios.
> But my customers sometimes ask for the ability to self define some matching
> rules, thus to support some special scenarios.
> I take below example as an illustration:
> {code:java}
> Query:
> select * from table
> where from_unixtime(_EVENT_TIME_, "mmdd hh") >= "20190909 00"
> and from_unixtime(_EVENT_TIME_, "mmdd hh") <= "20190909 23" ;
> Materialized View:
> select * from table
> where from_unixtime(_EVENT_TIME_, "mmdd") = "20190909";{code}
> It's hard to enumerate the matching pattern for different functions in
> internal matching rules. We can expose a method to register new UnifyRules
> and allow user to extend the ability of MV matching
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4486) UNIQUE predicate
[
https://issues.apache.org/jira/browse/CALCITE-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418403#comment-17418403
]
Julian Hyde commented on CALCITE-4486:
--
[~nobigo], Please review the changes I made in
[julianhyde/4486-unique|https://github.com/julianhyde/calcite/tree/4486-unique].
If they're OK I'll squash and merge.
> UNIQUE predicate
>
>
> Key: CALCITE-4486
> URL: https://issues.apache.org/jira/browse/CALCITE-4486
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Julian Hyde
>Assignee: duan xiong
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Implement the UNIQUE predicate, as specified by the SQL standard.
> Example:
> {code:java}
> UNIQUE (SELECT publishedIn FROM Book
> WHERE authorId = 3)
> NOT UNIQUE (SELECT publishedIn FROM BOOK
> WHERE authorId = 3)
> {code}
> {{UNIQUE}} returns {{FALSE}} if the query returns two or more rows that do
> not include NULL values and are equal. Like {{EXISTS}}, it never returns
> {{UNKNOWN}}.
> More details at
> [JOOQ|https://www.jooq.org/doc/3.0/manual/sql-building/conditional-expressions/unique-predicate/].
> This Issue support the UNIQUE predicate by set {{isExpand}} to return false,
> so sub-queries are converted to {{RexSubQuery}} expressions and handled later
> by {{SubQueryRemoveRule}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3583) Support serialized to json and deserialized from json for Exchange relation operator
[
https://issues.apache.org/jira/browse/CALCITE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418385#comment-17418385
]
xzh_dz edited comment on CALCITE-3583 at 9/22/21, 2:41 AM:
---
[~julianhyde]
thanks for review.
There is already a PR that supports `RelDistribution` serialization and
deserialization.but when I tested the unit test `{{testExchange`}}, I got the
message below.
`
java.lang.NullPointerException: no entry for tag collation
java.lang.RuntimeException: java.lang.NullPointerException: no entry for tag
collation
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:193)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:135)
`
So i create a new JIRA. Maybe this JIRA should be closed.
Please help review [Exchange operator deserialize
fail|https://github.com/apache/calcite/pull/2519]
was (Author: xzh_dz):
[~julianhyde]
thanks for review.
There is already a PR that supports `RelDistribution` serialization and
deserialization.but when I tested the unit test `{{testExchange`}}, I got the
message below.
`
java.lang.NullPointerException: no entry for tag collation
java.lang.RuntimeException: java.lang.NullPointerException: no entry for tag
collation
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:193)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:135)
`
So i create a new JIRA. Maybe this JIRA should be closed.
Please help review [Exchange operator deserialize
fail|[http://example.com|https://github.com/apache/calcite/pull/2519]]
> Support serialized to json and deserialized from json for Exchange relation
> operator
>
>
> Key: CALCITE-3583
> URL: https://issues.apache.org/jira/browse/CALCITE-3583
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Currently, serialize Exchange relnode to json will cause exception
> {code:java}
> // RelWriterTest
> @Test public void testExchange() {
> final FrameworkConfig config = RelBuilderTest.config().build();
> final RelBuilder builder = RelBuilder.create(config);
> final RelNode rel = builder
> .scan("EMP")
> .exchange(RelDistributions.hash(ImmutableList.of(0, 1)))
> .build();
> String relJson = RelOptUtil.dumpPlan("", rel,
> SqlExplainFormat.JSON, SqlExplainLevel.EXPPLAN_ATTRIBUTES);
> String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
> final String expected = ""
> + "LogicalExchange(distribution=[hash[0, 1]])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(s, isLinux(expected));
> }
> {code}
> got
> {code:java}
> java.lang.UnsupportedOperationException: type not serializable: hash[0, 1]
> (type org.apache.calcite.rel.RelDistributions.RelDistributionImpl)
> at org.apache.calcite.rel.externalize.RelJson.toJson(RelJson.java:290)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.put(RelJsonWriter.java:83)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.explain_(RelJsonWriter.java:66)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.done(RelJsonWriter.java:128)
> at
> org.apache.calcite.rel.AbstractRelNode.explain(AbstractRelNode.java:299)
> at org.apache.calcite.plan.RelOptUtil.dumpPlan(RelOptUtil.java:1981)
> at
> org.apache.calcite.plan.RelWriterTest.testExchange(RelWriterTest.java:772)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3583) Support serialized to json and deserialized from json for Exchange relation operator
[
https://issues.apache.org/jira/browse/CALCITE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418385#comment-17418385
]
xzh_dz commented on CALCITE-3583:
-
[~julianhyde]
thanks for review.
There is already a PR that supports `RelDistribution` serialization and
deserialization.but when I tested the unit test `{{testExchange`}}, I got the
message below.
`
java.lang.NullPointerException: no entry for tag collation
java.lang.RuntimeException: java.lang.NullPointerException: no entry for tag
collation
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:193)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:135)
`
So i create a new JIRA. Maybe this JIRA should be closed.
Please help review [Exchange operator deserialize
fail|[http://example.com|https://github.com/apache/calcite/pull/2519]]
> Support serialized to json and deserialized from json for Exchange relation
> operator
>
>
> Key: CALCITE-3583
> URL: https://issues.apache.org/jira/browse/CALCITE-3583
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Currently, serialize Exchange relnode to json will cause exception
> {code:java}
> // RelWriterTest
> @Test public void testExchange() {
> final FrameworkConfig config = RelBuilderTest.config().build();
> final RelBuilder builder = RelBuilder.create(config);
> final RelNode rel = builder
> .scan("EMP")
> .exchange(RelDistributions.hash(ImmutableList.of(0, 1)))
> .build();
> String relJson = RelOptUtil.dumpPlan("", rel,
> SqlExplainFormat.JSON, SqlExplainLevel.EXPPLAN_ATTRIBUTES);
> String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
> final String expected = ""
> + "LogicalExchange(distribution=[hash[0, 1]])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(s, isLinux(expected));
> }
> {code}
> got
> {code:java}
> java.lang.UnsupportedOperationException: type not serializable: hash[0, 1]
> (type org.apache.calcite.rel.RelDistributions.RelDistributionImpl)
> at org.apache.calcite.rel.externalize.RelJson.toJson(RelJson.java:290)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.put(RelJsonWriter.java:83)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.explain_(RelJsonWriter.java:66)
> at
> org.apache.calcite.rel.externalize.RelJsonWriter.done(RelJsonWriter.java:128)
> at
> org.apache.calcite.rel.AbstractRelNode.explain(AbstractRelNode.java:299)
> at org.apache.calcite.plan.RelOptUtil.dumpPlan(RelOptUtil.java:1981)
> at
> org.apache.calcite.plan.RelWriterTest.testExchange(RelWriterTest.java:772)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4786) Facilitate use of graalvm native-image compilation
[ https://issues.apache.org/jira/browse/CALCITE-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418381#comment-17418381 ] xzh_dz commented on CALCITE-4786: - It looks like very helpful to Calcite. > Facilitate use of graalvm native-image compilation > -- > > Key: CALCITE-4786 > URL: https://issues.apache.org/jira/browse/CALCITE-4786 > Project: Calcite > Issue Type: Improvement > Components: build >Reporter: Jacques Nadeau >Priority: Major > > Right now, there are number of things that make it difficult to use Calcite > with GraalVM native compilation. > There are several reasons that supporting this kind of compilation could be > beneficial: > - Enable use of Calcite as a Lambda with minimal startup-time > - Create a Calcite shared library that can be easily embedded in other > languages > Initially, I would focus this work on core parsing and query planning. > This work was inspired by work on https://substrait.io > Let's use this ticket to track improvements that can be done to enable this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4783) RelFieldTrimmer incorrectly drops filter condition
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xzh_dz updated CALCITE-4783:
Description:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
trimmed:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
In this case,RelFieldTrimmer incorrectly drops filter
condition.`RelNode(trimmed)` is incorrect,there is no predicate condition
`ename = '1'` in final `RelNode(trimmed)`.During Calc operator trim, predicates
should not be lost.
was:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
trimmed:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
In this case,`RelNode(trimmed)` is incorrect,there is no predicate condition
`ename = '1'` in final `RelNode(trimmed)`.During Calc operator trim, predicates
should not be lost.
> RelFieldTrimmer incorrectly drops filter condition
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> trimmed:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> In this case,RelFieldTrimmer incorrectly drops filter
> condition.`RelNode(trimmed)` is incorrect,there is no predicate condition
> `ename = '1'` in final `RelNode(trimmed)`.During C
[jira] [Commented] (CALCITE-4783) RelFieldTrimmer incorrectly drops filter condition
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418377#comment-17418377
]
xzh_dz commented on CALCITE-4783:
-
Thanks,i have updated the description.
> RelFieldTrimmer incorrectly drops filter condition
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> trimmed:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> In this case,`RelNode(trimmed)` is incorrect,there is no predicate condition
> `ename = '1'` in final `RelNode(trimmed)`.During Calc operator trim,
> predicates should not be lost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4783) RelFieldTrimmer incorrectly drops filter condition
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xzh_dz updated CALCITE-4783:
Description:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
trimmed:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
In this case,`RelNode(trimmed)` is incorrect,there is no predicate condition
`ename = '1'` in final `RelNode(trimmed)`.During Calc operator trim, predicates
should not be lost.
was:
{code:java}
// code placeholder
org.apache.calcite.test.SqlToRelConverterTest
@Test void testTrim() {
final String sql = "select count(*) from emp where ename = '1'";
final RelNode rel = tester.convertSqlToRel(sql).rel;
final HepProgramBuilder programBuilder = HepProgram.builder();
programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
final HepPlanner planner = new HepPlanner(programBuilder.build());
planner.setRoot(rel);
final RelNode calc = planner.findBestExp();
final List relOptTables = RelOptUtil.findAllTables(calc);
RelOptSchema relOptSchema = null;
if (relOptTables.size() != 0) {
relOptSchema = relOptTables.get(0).getRelOptSchema();
}
final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
calc.getCluster(), relOptSchema);
final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
final RelNode trimmed = fieldTrimmer.trim(calc);
System.out.println(RelOptUtil.toString(trimmed));
}
rel:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[0])
LogicalFilter(condition=[=($1, '1')])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
result:
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> RelFieldTrimmer incorrectly drops filter condition
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> trimmed:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
> In this case,`RelNode(trimmed)` is incorrect,there is no predicate condition
> `ename = '1'` in final `RelNode(trimmed)`.During Calc operator trim,
> predicates should not be lost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4754) Invalid Redshift SQL when executing a PIVOT query
[
https://issues.apache.org/jira/browse/CALCITE-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418369#comment-17418369
]
Javier Rivas Rodriguez commented on CALCITE-4754:
-
Hi [~julianhyde], I have opened a [draft
PR|https://github.com/apache/calcite/pull/2532] with several commits as
suggested, to work on these changes.
I have left _supportsIsTrueInsideCaseWhen_ as it was temporarily. I think I'm
not able to completely understand the changes you are requesting and I'd need
some help clarifying them. At the moment in a filter operation, the IS TRUE
operator is added
[here|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5733]
tracking it to CALCITE-1042 and it gets carried over to the CASE (WHEN
transformation. There are also
[tests|https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L224-L254]
in the codebase verifying it is added. That is what led me to think that I
could add the option of removing it based on the dialect.
As I have mentioned earlier, I'm keen to get some more directions on how to
approach the problem if this is not the right angle and make those changes.
> Invalid Redshift SQL when executing a PIVOT query
> -
>
> Key: CALCITE-4754
> URL: https://issues.apache.org/jira/browse/CALCITE-4754
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Javier Rivas Rodriguez
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Given a Calcite connection to Redshift
> When running a query like the one below
> {code:java}
> SELECT *
> FROM
> (SELECT field1, field2, field3
>FROM my_table)
> PIVOT SUM(field1) FOR field2 IN (val1, val2){code}
> The SQL produced is something like
> {code:java}
> SELECT
> field3,
> SUM(field1) FILTER (WHERE field2 = val1),
> SUM(field1) FILTER (WHERE field2 = val2)
> FROM my_table
> GROUP BY field3{code}
> This SQL transformation is not accepted by Redshift
> The expected result would be something like
> {code:java}
> SELECT
> field3,
> SUM(CASE WHEN field2 = val1 THEN field1 ELSE NULL END),
> SUM(CASE WHEN field2 = val2 THEN field1 ELSE NULL END)
> FROM my_table
> GROUP BY field3
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4786) Facilitate use of graalvm native-image compilation
[
https://issues.apache.org/jira/browse/CALCITE-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418365#comment-17418365
]
Jacques Nadeau commented on CALCITE-4786:
-
{quote}Sounds like an exciting project.
{quote}
Definitely. Would love to have you involved in any way you'd be interested!
> Facilitate use of graalvm native-image compilation
> --
>
> Key: CALCITE-4786
> URL: https://issues.apache.org/jira/browse/CALCITE-4786
> Project: Calcite
> Issue Type: Improvement
> Components: build
>Reporter: Jacques Nadeau
>Priority: Major
>
> Right now, there are number of things that make it difficult to use Calcite
> with GraalVM native compilation.
> There are several reasons that supporting this kind of compilation could be
> beneficial:
> - Enable use of Calcite as a Lambda with minimal startup-time
> - Create a Calcite shared library that can be easily embedded in other
> languages
> Initially, I would focus this work on core parsing and query planning.
> This work was inspired by work on https://substrait.io
> Let's use this ticket to track improvements that can be done to enable this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4789) Build is broken on Guava versions < 21
[
https://issues.apache.org/jira/browse/CALCITE-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418360#comment-17418360
]
Julian Hyde commented on CALCITE-4789:
--
[~asolimando], The test
{{CassandraAdapterDataTypesTest.testCollectionsInnerValues}}, for which you
changed the expected result in CALCITE-4301, gives the wrong result (i.e.
returns the result that it did before your change) when run under Guava 19.0.
Can you look into it, please? We need the tests to work on all Guava versions
19 through 29.
> Build is broken on Guava versions < 21
> --
>
> Key: CALCITE-4789
> URL: https://issues.apache.org/jira/browse/CALCITE-4789
> Project: Calcite
> Issue Type: Bug
> Environment: The build is currently broken on Guava versions 20 and
> lower. We claim in the release notes to support Guava 19 and higher.
> As part of this change, enable testing in CI of the lowest and highest
> supported Guava version. (We used to do this, but we stopped when we moved
> from Maven to Gradle. I still don't know how to set the Guava version from
> the Gradle command line.)
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.28.0
>
>
> The build is broken on versions of Gradle less than 21. In our release notes
> we say we support Gradle 19 and higher.
> We used to test the supported range of Guava versions in CI. The fix for this
> issue must resume CI testing for the range of supported versions (currently
> 19.0 to 29.0-jre per
> [history.md|https://calcite.apache.org/docs/history.html] and 19.0 and higher
> per a comment in {{gradle.properties}}).
> How do I set the Guava version from the Gradle command line? I’d expect
> {code:java}
> ./gradlew -Dguava.version=19.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4789) Build is broken on Guava versions < 21
[
https://issues.apache.org/jira/browse/CALCITE-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-4789:
-
Description:
The build is broken on versions of Gradle less than 21. In our release notes we
say we support Gradle 19 and higher.
We used to test the supported range of Guava versions in CI. The fix for this
issue must resume CI testing for the range of supported versions (currently
19.0 to 29.0-jre per [history.md|https://calcite.apache.org/docs/history.html]
and 19.0 and higher per a comment in {{gradle.properties}}).
How do I set the Guava version from the Gradle command line? I’d expect
{code:java}
./gradlew -Dguava.version=19.0
{code}
> Build is broken on Guava versions < 21
> --
>
> Key: CALCITE-4789
> URL: https://issues.apache.org/jira/browse/CALCITE-4789
> Project: Calcite
> Issue Type: Bug
> Environment: The build is currently broken on Guava versions 20 and
> lower. We claim in the release notes to support Guava 19 and higher.
> As part of this change, enable testing in CI of the lowest and highest
> supported Guava version. (We used to do this, but we stopped when we moved
> from Maven to Gradle. I still don't know how to set the Guava version from
> the Gradle command line.)
>Reporter: Julian Hyde
>Priority: Major
> Fix For: 1.28.0
>
>
> The build is broken on versions of Gradle less than 21. In our release notes
> we say we support Gradle 19 and higher.
> We used to test the supported range of Guava versions in CI. The fix for this
> issue must resume CI testing for the range of supported versions (currently
> 19.0 to 29.0-jre per
> [history.md|https://calcite.apache.org/docs/history.html] and 19.0 and higher
> per a comment in {{gradle.properties}}).
> How do I set the Guava version from the Gradle command line? I’d expect
> {code:java}
> ./gradlew -Dguava.version=19.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4789) Build is broken on Guava versions < 21
[
https://issues.apache.org/jira/browse/CALCITE-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-4789:
Assignee: Julian Hyde
> Build is broken on Guava versions < 21
> --
>
> Key: CALCITE-4789
> URL: https://issues.apache.org/jira/browse/CALCITE-4789
> Project: Calcite
> Issue Type: Bug
> Environment: The build is currently broken on Guava versions 20 and
> lower. We claim in the release notes to support Guava 19 and higher.
> As part of this change, enable testing in CI of the lowest and highest
> supported Guava version. (We used to do this, but we stopped when we moved
> from Maven to Gradle. I still don't know how to set the Guava version from
> the Gradle command line.)
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.28.0
>
>
> The build is broken on versions of Gradle less than 21. In our release notes
> we say we support Gradle 19 and higher.
> We used to test the supported range of Guava versions in CI. The fix for this
> issue must resume CI testing for the range of supported versions (currently
> 19.0 to 29.0-jre per
> [history.md|https://calcite.apache.org/docs/history.html] and 19.0 and higher
> per a comment in {{gradle.properties}}).
> How do I set the Guava version from the Gradle command line? I’d expect
> {code:java}
> ./gradlew -Dguava.version=19.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4789) Build is broken on Guava versions < 21
[ https://issues.apache.org/jira/browse/CALCITE-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418356#comment-17418356 ] Julian Hyde commented on CALCITE-4789: -- Work in progress: [julianhyde/4789-guava-19|https://github.com/julianhyde/calcite/tree/4789-guava-19]. > Build is broken on Guava versions < 21 > -- > > Key: CALCITE-4789 > URL: https://issues.apache.org/jira/browse/CALCITE-4789 > Project: Calcite > Issue Type: Bug > Environment: The build is currently broken on Guava versions 20 and > lower. We claim in the release notes to support Guava 19 and higher. > As part of this change, enable testing in CI of the lowest and highest > supported Guava version. (We used to do this, but we stopped when we moved > from Maven to Gradle. I still don't know how to set the Guava version from > the Gradle command line.) >Reporter: Julian Hyde >Priority: Major > Fix For: 1.28.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4789) Build is broken on Guava versions < 21
Julian Hyde created CALCITE-4789: Summary: Build is broken on Guava versions < 21 Key: CALCITE-4789 URL: https://issues.apache.org/jira/browse/CALCITE-4789 Project: Calcite Issue Type: Bug Environment: The build is currently broken on Guava versions 20 and lower. We claim in the release notes to support Guava 19 and higher. As part of this change, enable testing in CI of the lowest and highest supported Guava version. (We used to do this, but we stopped when we moved from Maven to Gradle. I still don't know how to set the Guava version from the Gradle command line.) Reporter: Julian Hyde -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4789) Build is broken on Guava versions < 21
[ https://issues.apache.org/jira/browse/CALCITE-4789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-4789: - Fix Version/s: 1.28.0 > Build is broken on Guava versions < 21 > -- > > Key: CALCITE-4789 > URL: https://issues.apache.org/jira/browse/CALCITE-4789 > Project: Calcite > Issue Type: Bug > Environment: The build is currently broken on Guava versions 20 and > lower. We claim in the release notes to support Guava 19 and higher. > As part of this change, enable testing in CI of the lowest and highest > supported Guava version. (We used to do this, but we stopped when we moved > from Maven to Gradle. I still don't know how to set the Guava version from > the Gradle command line.) >Reporter: Julian Hyde >Priority: Major > Fix For: 1.28.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4686) SubQueryRemoveRule.matchJoin should correctly rewrite all sub-queries
[
https://issues.apache.org/jira/browse/CALCITE-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418210#comment-17418210
]
James Starr commented on CALCITE-4686:
--
Hi [~zabetak],
Great find! I have looked into your patch and see the bug you are referring
to. The correlated variable index is referencing the indexes from the join.
So when a correlated variable from right side is referenced, it is incorrectly
shifted. This also occurs when the RelBuilder.join rewrites a join node to a
correlate node. I am still looking into potential fixes.
James
> SubQueryRemoveRule.matchJoin should correctly rewrite all sub-queries
> -
>
> Key: CALCITE-4686
> URL: https://issues.apache.org/jira/browse/CALCITE-4686
> Project: Calcite
> Issue Type: Improvement
>Reporter: James Starr
>Assignee: James Starr
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> SubQueryRemoveRule.matchJoin only rewrites the first subquery in an ON
> condition each call. It should rewrite all of them down right side of the
> join in single call. Furthermore, the filter generated is not shifted
> correctly for the scope that it is being applied to.
> RelOptRulesTest.testExpandJoinIn, which currently disabled, throw an
> exception when run because filter is shifted to be applied to in the context
> of the right side but it applied on top of the join. Which can be observed
> by commenting out the litmus check.
> {code:java}
> @Test void testExpandJoinIn() {
> final String sql = "select empno\n"
> + "from sales.emp left join sales.dept\n"
> + "on emp.deptno in (select deptno from sales.emp where empno < 20)";
> checkSubQuery(sql).check();
> }
> {code}
> {noformat}
> RexInputRef index 7 out of range 0..2
> java.lang.AssertionError: RexInputRef index 7 out of range 0..2
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:125)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at org.apache.calcite.rel.core.Join.isValid(Join.java:176)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:4261)
> at org.apache.calcite.rel.BiRel.childrenAccept(BiRel.java:46)
> at org.apache.calcite.rel.RelVisitor.visit(RelVisitor.java:46)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:4264)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at org.apache.calcite.rel.RelVisitor.visit(RelVisitor.java:46)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:4264)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at org.apache.calcite.rel.RelVisitor.visit(RelVisitor.java:46)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:4264)
> at org.apache.calcite.rel.RelVisitor.go(RelVisitor.java:63)
> at
> org.apache.calcite.test.SqlToRelTestBase.assertValid(SqlToRelTestBase.java:154)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:163)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:109)
> at
> org.apache.calcite.test.RelOptTestBase.access$100(RelOptTestBase.java:66)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:340)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:316)
> at
> org.apache.calcite.test.RelOptRulesTest.testExpandJoinIn(RelOptRulesTest.java:5702)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:675)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInter
[jira] [Updated] (CALCITE-4783) RelFieldTrimmer incorrectly drops filter condition
[
https://issues.apache.org/jira/browse/CALCITE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-4783:
-
Summary: RelFieldTrimmer incorrectly drops filter condition (was: Dropped
the predicate condition after RelFieldTrimmer trim the RelNode)
> RelFieldTrimmer incorrectly drops filter condition
> --
>
> Key: CALCITE-4783
> URL: https://issues.apache.org/jira/browse/CALCITE-4783
> Project: Calcite
> Issue Type: Improvement
>Reporter: xzh_dz
>Priority: Major
>
> {code:java}
> // code placeholder
> org.apache.calcite.test.SqlToRelConverterTest
> @Test void testTrim() {
> final String sql = "select count(*) from emp where ename = '1'";
> final RelNode rel = tester.convertSqlToRel(sql).rel;
> final HepProgramBuilder programBuilder = HepProgram.builder();
> programBuilder.addRuleInstance(CoreRules.FILTER_TO_CALC);
> final HepPlanner planner = new HepPlanner(programBuilder.build());
> planner.setRoot(rel);
> final RelNode calc = planner.findBestExp();
> final List relOptTables = RelOptUtil.findAllTables(calc);
> RelOptSchema relOptSchema = null;
> if (relOptTables.size() != 0) {
> relOptSchema = relOptTables.get(0).getRelOptSchema();
> }
> final RelBuilder relBuilder = RelFactories.LOGICAL_BUILDER.create(
> calc.getCluster(), relOptSchema);
> final RelFieldTrimmer fieldTrimmer = new RelFieldTrimmer(null, relBuilder);
> final RelNode trimmed = fieldTrimmer.trim(calc);
> System.out.println(RelOptUtil.toString(trimmed));
> }
> rel:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalProject($f0=[0])
> LogicalFilter(condition=[=($1, '1')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> result:
> LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4773) RelDecorrelator's RemoveSingleAggregateRule can produce result with wrong row type
[
https://issues.apache.org/jira/browse/CALCITE-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17417985#comment-17417985
]
Ruben Q L commented on CALCITE-4773:
Comments have been improved, they include now an example of the rule's
application.
> RelDecorrelator's RemoveSingleAggregateRule can produce result with wrong row
> type
> --
>
> Key: CALCITE-4773
> URL: https://issues.apache.org/jira/browse/CALCITE-4773
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The problem can be reproduced with the following test (to be added to
> {{unnest.iq}}):
> {noformat}
> SELECT unnested_outer.val, COUNT(1) AS count_val
> FROM
> (
> SELECT *
> FROM (VALUES (1, array [3, 5]), (2, array [6, 4, 6]))
> AS u(x, y)
> ) AS t, UNNEST(t.y) AS unnested_outer(val)
> WHERE
> (
> SELECT COUNT(unnested_inner.val) > 0
> FROM UNNEST(t.y) AS unnested_inner(val)
> WHERE unnested_inner.val = 4
> )
> GROUP BY unnested_outer.val
> ORDER BY count_val DESC, unnested_outer.val ASC;
> +-+---+
> | VAL | COUNT_VAL |
> +-+---+
> | 6 | 2 |
> | 4 | 1 |
> +-+---+
> (2 rows)
> !ok
> {noformat}
> When the test is executed, it fails with the following error:
> {noformat}
> > java.lang.AssertionError: Cannot add expression of different type to set:
> > set type is RecordType(BOOLEAN NOT NULL $f0) NOT NULL
> > expression type is RecordType(BOOLEAN $f0) NOT NULL
> > set is
> > rel#24436:LogicalAggregate.NONE.[](input=HepRelVertex#24435,group={},agg#0=SINGLE_VALUE($0))
> > expression is LogicalProject($f0=[CAST(>($0, 0)):BOOLEAN])
> > LogicalAggregate(group=[{}], agg#0=[COUNT()])
> > LogicalFilter(condition=[=($0, 4)])
> > LogicalProject(VAL=[$0])
> > Uncollect
> > LogicalProject(Y=[$cor1.Y])
> > LogicalValues(tuples=[[{ 0 }]])
> 249a254,325
> > at
> > org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:391)
> > at
> > org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:60)
> > at
> > org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:269)
> > at
> > org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:284)
> > at
> > org.apache.calcite.sql2rel.RelDecorrelator$RemoveSingleAggregateRule.onMatch(RelDecorrelator.java:1923)
> > at
> > org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:341)
> > at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
> > at
> > org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:130)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> > at
> > org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> > at
> > org.apache.calcite.sql2rel.RelDecorrelator.removeCorrelationViaRule(RelDecorrelator.java:378)
> > at
> > org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:221)
> ...
> {noformat}
> The root cause seems to be in this piece of code inside {{RelDecorrelator}}'s
> {{RemoveSingleAggregateRule#onMatch}}:
> {code:java}
> // singleAggRel produces a nullable type, so create the new
> // projection that casts proj expr to a nullable type.
> final RelBuilder relBuilder = call.builder();
> final RelDataType type =
> relBuilder.getTypeFactory()
> .createTypeWithNullability(projExprs.get(0).getType(), true);
> final RexNode cast = relBuilder.getRexBuilder().makeCast(type,
> projExprs.get(0));
> relBuilder.push(aggregate).project(cast);
> call.transformTo(relBuilder.build());
> {code}
> Note that the comment assumes that _"singleAggRel produces a nullable type"_,
> but in this particular case, it seems to produce a non-nullable type, so
> probably this piece of code needs to be adapted.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
