[jira] [Created] (CALCITE-5195) ArrayIndexOutOfBoundsException when inferring more equal conditions from join condition for semi join
Chunwei Lei created CALCITE-5195:
Summary: ArrayIndexOutOfBoundsException when inferring more equal
conditions from join condition for semi join
Key: CALCITE-5195
URL: https://issues.apache.org/jira/browse/CALCITE-5195
Project: Calcite
Issue Type: Bug
Reporter: Chunwei Lei
Assignee: Chunwei Lei
The following test can reproduce the exception.
{code:java}
@Test void testJoinConditionPushdown4() {
final Function relFn = b -> {
RelNode left = b.scan("EMP")
.project(
b.field("DEPTNO"),
b.field("ENAME"))
.build();
RelNode right = b.scan("DEPT")
.project(
b.field("DEPTNO"),
b.field("DNAME"))
.build();
b.push(left).push(right);
RexInputRef ref1 = b.field(2, 0, "DEPTNO");
RexInputRef ref2 = b.field(2, 1, "DEPTNO");
RexInputRef ref3 = b.field(2, 1, "DNAME");
RexCall cond1 = (RexCall) b.equals(ref1, ref2);
RexCall cond2 = (RexCall) b.equals(ref1, ref3);
RexNode cond = b.and(cond1, cond2);
return b.semiJoin(cond)
.project(b.field(0))
.build();
};
relFn(relFn)
.withRule(
CoreRules.JOIN_PUSH_EXPRESSIONS,
CoreRules.JOIN_CONDITION_PUSH,
CoreRules.SEMI_JOIN_PROJECT_TRANSPOSE,
CoreRules.JOIN_REDUCE_EXPRESSIONS,
CoreRules.FILTER_REDUCE_EXPRESSIONS)
.check();
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5193) Push filter whose conditions include join keys and are composed by OR into inputs of full join
Chunwei Lei created CALCITE-5193:
Summary: Push filter whose conditions include join keys and are
composed by OR into inputs of full join
Key: CALCITE-5193
URL: https://issues.apache.org/jira/browse/CALCITE-5193
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
For example,
{code:java}
select * from a full join b on a.id=b.id where a.id=1 or b.id=2
{code}
can be transformed to
{code:java}
select * from
(select * from a where id=1) a
full join
(select * from b where id=2) b
on a.id=b.id;
{code}
If {{a}} and {{b}} are both partitioned tables and id is the partition key, we
can do partition pruning with this transformation, which is a big improvement.
This improvement is inspired by query
{code:java}
select * from a full join b on a.id=b.id and a.pt=b.pt where COALESCE(a.pt,
b.pt)='20220601';
{code}
which costs a lot due to it scans all partitions in table a and b.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5162) RelMdUniqueKeys can return more precise unique keys for Aggregate
Chunwei Lei created CALCITE-5162:
Summary: RelMdUniqueKeys can return more precise unique keys for
Aggregate
Key: CALCITE-5162
URL: https://issues.apache.org/jira/browse/CALCITE-5162
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
Assignee: Chunwei Lei
Currently, RelMdUniqueKeys always returns group by keys as the unique key.
However, it can return more precise unique keys by looking through group by
keys. For instance:
{code:java}
select deptno, deptname, count(*) from dept group by deptno, deptname;{code}
RelMdUniqueKeys can return {{deptno}} as the unique key instead of (deptno,
deptname) if {{deptno}} is unique.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5149) Refine RelMdColumnUniqueness for Window by considering partition keys
Chunwei Lei created CALCITE-5149:
Summary: Refine RelMdColumnUniqueness for Window by considering
partition keys
Key: CALCITE-5149
URL: https://issues.apache.org/jira/browse/CALCITE-5149
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
Assignee: Chunwei Lei
Currently, RelMdColumnUniqueness always returns null when meeting the Window
operator. We can improve it by considering its partition keys. For instance,
{code:java}
select empno, rank () over (partition by empno order by empno) as rn from
emp{code}
If {{empno}} is the primary key of the table, {{empno}} is unique obviously.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (CALCITE-5131) Remove redundant type cast
Chunwei Lei created CALCITE-5131: Summary: Remove redundant type cast Key: CALCITE-5131 URL: https://issues.apache.org/jira/browse/CALCITE-5131 Project: Calcite Issue Type: Improvement Reporter: Chunwei Lei Assignee: Chunwei Lei Attachments: index.html, script.js, styles.css There're a number of redundant type casts. I suggest removing them. !image-2022-05-05-10-57-58-717.png! What do you think? BTW, it seems the CheckStyle plugin doesn't provide such a check. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (CALCITE-4895) MAP type in UDF cannot be externalized from json correctly
Chunwei Lei created CALCITE-4895:
Summary: MAP type in UDF cannot be externalized from json correctly
Key: CALCITE-4895
URL: https://issues.apache.org/jira/browse/CALCITE-4895
Project: Calcite
Issue Type: Bug
Reporter: Chunwei Lei
{code:java}
// code placeholder
java.lang.RuntimeException: java.lang.RuntimeException:
java.lang.AssertionError: use createMapType() instead
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:193)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:135)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:153)
at
org.apache.calcite.plan.RelWriterTest.deserializeAndDump(RelWriterTest.java:1024)
at
org.apache.calcite.plan.RelWriterTest.deserializeAndDumpToTextFormat(RelWriterTest.java:1044)
at org.apache.calcite.plan.RelWriterTest.testMapType(RelWriterTest.java:978)
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:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at
org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
at
org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
[jira] [Created] (CALCITE-4893) JsonParseException happens when externalizing expressions with escape character from JSON
Chunwei Lei created CALCITE-4893:
Summary: JsonParseException happens when externalizing expressions
with escape character from JSON
Key: CALCITE-4893
URL: https://issues.apache.org/jira/browse/CALCITE-4893
Project: Calcite
Issue Type: Bug
Reporter: Chunwei Lei
Assignee: Chunwei Lei
The following test can reproduce the error.
{code:java}
// RelWriterTest.java
@Test void testEscapeCharacter() {
final FrameworkConfig config = RelBuilderTest.config().build();
final RelBuilder builder = RelBuilder.create(config);
final RelNode rel = builder
.scan("EMP")
.project(
builder.call(new MockSqlOperatorTable.SplitFunction(),
builder.field("ENAME"), builder.literal("\r")))
.build();
final String relJson = RelOptUtil.dumpPlan("", rel,
SqlExplainFormat.JSON, SqlExplainLevel.EXPPLAN_ATTRIBUTES);
final String s = deserializeAndDumpToTextFormat(getSchema(rel), relJson);
final String expected = ""
+ "LogicalProject($f0=[SPLIT($1, '\r')])\n"
+ " LogicalTableScan(table=[[scott, EMP]])\n";
assertThat(s, isLinux(expected));
} {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4884) Provide a new constructor for RelJsonWriter to allow customized JsonBuilder
Chunwei Lei created CALCITE-4884:
Summary: Provide a new constructor for RelJsonWriter to allow
customized JsonBuilder
Key: CALCITE-4884
URL: https://issues.apache.org/jira/browse/CALCITE-4884
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
Currently JsonBuilder in RelJsonWriter cannot be customized due to it being
created in the constructor. We can provide a new constructor for RelJsonWriter
to allow customized JsonBuilder.
{code:java}
// code placeholder
public RelJsonWriter() {
jsonBuilder = new JsonBuilder();
relList = jsonBuilder.list();
relJson = new RelJson(jsonBuilder);
}
// the new constrctor suggested.
public RelJsonWriter(JsonBuilder jsonBuilder) {
this.jsonBuilder = jsonBuilder;
relList = jsonBuilder.list();
relJson = new RelJson(jsonBuilder);
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4883) The traitset of Exchange operator losses the distribution when externalizing Exchange operator from JSON
Chunwei Lei created CALCITE-4883:
Summary: The traitset of Exchange operator losses the distribution
when externalizing Exchange operator from JSON
Key: CALCITE-4883
URL: https://issues.apache.org/jira/browse/CALCITE-4883
Project: Calcite
Issue Type: Bug
Reporter: Chunwei Lei
Assignee: Chunwei Lei
{code:java}
// code placeholder
// input.getTraitSet() might have no same distribution
protected Exchange(RelInput input) {
this(input.getCluster(), input.getTraitSet(), input.getInput(),
RelDistributionTraitDef.INSTANCE.canonize(input.getDistribution()));
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4429) createCastRel should throw an exception when the field count of the row type to to be converted and desired row type is not equal
Chunwei Lei created CALCITE-4429: Summary: createCastRel should throw an exception when the field count of the row type to to be converted and desired row type is not equal Key: CALCITE-4429 URL: https://issues.apache.org/jira/browse/CALCITE-4429 Project: Calcite Issue Type: Improvement Reporter: Chunwei Lei Assignee: Chunwei Lei See discussion in: https://issues.apache.org/jira/browse/CALCITE-4421 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4421) AssertionError is thrown with empty message
Chunwei Lei created CALCITE-4421:
Summary: AssertionError is thrown with empty message
Key: CALCITE-4421
URL: https://issues.apache.org/jira/browse/CALCITE-4421
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
Assignee: Chunwei Lei
I happened to meet the following error:
{code:java}
System internal error - java.lang.AssertionError
at org.apache.calcite.util.Pair.zip(Pair.java:202)
at org.apache.calcite.rex.RexUtil.generateCastExpressions(RexUtil.java:134)
at org.apache.calcite.rex.RexUtil.generateCastExpressions(RexUtil.java:116)
at org.apache.calcite.plan.RelOptUtil.createCastRel(RelOptUtil.java:728)
{code}
I checked the code and then It indeed would throw an exception with an empty
message.
{code:java}
public static List> zip(
final List ks,
final List vs,
boolean strict) {
final int size;
if (strict) {
if (ks.size() != vs.size()) {
throw new AssertionError();
}
{code}
I think a more useful exception message would be much better.
BTW, there're many other places like this:
{code:java}
calcite$ grep 'new AssertionError()' -r ./ -l
.//core/src/test/java/org/apache/calcite/test/catalog/MockCatalogReaderExtended.java
.//core/src/main/java/org/apache/calcite/util/mapping/IntPair.java
.//core/src/main/java/org/apache/calcite/util/NlsString.java
.//core/src/main/java/org/apache/calcite/util/Pair.java
.//core/src/main/java/org/apache/calcite/util/PrecedenceClimbingParser.java
.//core/src/main/java/org/apache/calcite/util/ImmutableBeans.java
.//core/src/main/java/org/apache/calcite/plan/RelTraitPropagationVisitor.java
.//core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java
.//core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableTableModify.java
.//core/src/main/java/org/apache/calcite/adapter/jdbc/JdbcRules.java
.//core/src/main/java/org/apache/calcite/jdbc/CalciteConnectionImpl.java
.//core/src/main/java/org/apache/calcite/rex/RexLiteral.java
.//core/src/main/java/org/apache/calcite/rex/RexInterpreter.java
.//core/src/main/java/org/apache/calcite/rex/RexBuilder.java
.//core/src/main/java/org/apache/calcite/rex/RexSimplify.java
.//core/src/main/java/org/apache/calcite/rel/rules/LoptMultiJoin.java
.//core/src/main/java/org/apache/calcite/rel/rules/ProjectTableScanRule.java
.//core/src/main/java/org/apache/calcite/rel/rules/FilterTableScanRule.java
.//core/src/main/java/org/apache/calcite/rel/metadata/RelMdColumnUniqueness.java
.//core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java
.//core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java
.//core/src/main/java/org/apache/calcite/materialize/Lattice.java
.//core/src/main/java/org/apache/calcite/sql/SqlFilterOperator.java
.//core/src/main/java/org/apache/calcite/sql/fun/SqlIntervalOperator.java
.//core/src/main/java/org/apache/calcite/sql/fun/SqlSubstringFunction.java
.//core/src/main/java/org/apache/calcite/sql/fun/SqlTranslate3Function.java
.//core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java
.//core/src/main/java/org/apache/calcite/sql/fun/SqlTrimFunction.java
.//core/src/main/java/org/apache/calcite/sql/fun/SqlDotOperator.java
.//core/src/main/java/org/apache/calcite/sql/fun/SqlPositionFunction.java
.//core/src/main/java/org/apache/calcite/sql/parser/SqlParserUtil.java
.//core/src/main/java/org/apache/calcite/sql/parser/SqlParserPos.java
.//core/src/main/java/org/apache/calcite/sql/type/CompositeOperandTypeChecker.java
.//core/src/main/java/org/apache/calcite/sql/SqlCallBinding.java
.//core/src/main/java/org/apache/calcite/sql/SqlOperator.java
.//file/src/test/java/org/apache/calcite/adapter/file/FileAdapterTest.java
.//example/csv/src/test/java/org/apache/calcite/test/CsvTest.java
.//mongodb/src/main/java/org/apache/calcite/adapter/mongodb/MongoRules.java
{code}
Should we change all of them?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4368) TopDownOptTest fails if applying non-substitution rule first
Chunwei Lei created CALCITE-4368:
Summary: TopDownOptTest fails if applying non-substitution rule
first
Key: CALCITE-4368
URL: https://issues.apache.org/jira/browse/CALCITE-4368
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
Assignee: Chunwei Lei
If we apply non-substitution rules first, some tests in TopDownOptTest would
fail. For example: TopDownOptTest#testSortMergeJoin
{code:java}
// code placeholder
java.lang.AssertionErrorjava.lang.AssertionError at
org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.(EnumerableMergeJoin.java:75)
at
org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:380)
at
org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:65)
at org.apache.calcite.rel.core.Join.copy(Join.java:310) at
org.apache.calcite.rel.core.Join.copy(Join.java:59) at
org.apache.calcite.rel.PhysicalNode.passThrough(PhysicalNode.java:88) at
org.apache.calcite.plan.volcano.RelSubset.passThrough(RelSubset.java:474) at
org.apache.calcite.plan.volcano.TopDownRuleDriver.convert(TopDownRuleDriver.java:582)
at
org.apache.calcite.plan.volcano.TopDownRuleDriver.getOptimizeInputTask(TopDownRuleDriver.java:547)
at
org.apache.calcite.plan.volcano.TopDownRuleDriver.access$400(TopDownRuleDriver.java:49)
at
org.apache.calcite.plan.volcano.TopDownRuleDriver$OptimizeGroup.perform(TopDownRuleDriver.java:349)
at
org.apache.calcite.plan.volcano.TopDownRuleDriver.drive(TopDownRuleDriver.java:103)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:520)
at
org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:122)
at org.apache.calcite.test.RelOptTestBase.access$000(RelOptTestBase.java:64) at
org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:303) at
org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:282) at
org.apache.calcite.test.Query.check(TopDownOptTest.java:824) at
org.apache.calcite.test.TopDownOptTest.testSortMergeJoin(TopDownOptTest.java:100)
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(InvocationInterceptorChain.java:125)
at
org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:139)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:81)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:104)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:62)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:43)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:35)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:202)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:198)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:69)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
[jira] [Created] (CALCITE-4360) Should apply SubstituteRule first in top-down driven rule apply
Chunwei Lei created CALCITE-4360: Summary: Should apply SubstituteRule first in top-down driven rule apply Key: CALCITE-4360 URL: https://issues.apache.org/jira/browse/CALCITE-4360 Project: Calcite Issue Type: Improvement Reporter: Chunwei Lei Assignee: Chunwei Lei Attachments: image-2020-10-27-21-55-55-155.png !image-2020-10-27-21-55-55-155.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4239) RelMdUniqueKeys returns wrong unique keys for Aggregate with grouping sets
Chunwei Lei created CALCITE-4239:
Summary: RelMdUniqueKeys returns wrong unique keys for Aggregate
with grouping sets
Key: CALCITE-4239
URL: https://issues.apache.org/jira/browse/CALCITE-4239
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Chunwei Lei
For Aggregate with grouping sets, group by keys might not form a unique key.
For example:
{code:java}
//PostgreSQL
create table test2(key bigint, value bigint);
insert into test2 values
(1, null),
(null, 1);
select key, value, count(*) from test2
group by GROUPING SETS (key,value)
;
postgres=# select key, value, count(*) from test2
postgres-# group by GROUPING SETS (key,value)
postgres-# ;
key | value | count
-+---+---
| | 1
1 | | 1
| | 1
| 1 | 1
(4 rows)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4223) Introducing column statistics to RelOptTable
Chunwei Lei created CALCITE-4223: Summary: Introducing column statistics to RelOptTable Key: CALCITE-4223 URL: https://issues.apache.org/jira/browse/CALCITE-4223 Project: Calcite Issue Type: Improvement Reporter: Chunwei Lei Many systems depend on column statistics to compute more accurate stats, such as NDV, average column size, and so on. It would be nice if Calcite can provide such an interface. Column statistics might include NDV, average/max column length, number of nulls, number of trues, number of falses and so on. What do you think? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4203) RelMdUniqueKeys should not return empty when meeting Intersect and Minus if its input has unique keys
Chunwei Lei created CALCITE-4203:
Summary: RelMdUniqueKeys should not return empty when meeting
Intersect and Minus if its input has unique keys
Key: CALCITE-4203
URL: https://issues.apache.org/jira/browse/CALCITE-4203
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
Assignee: Chunwei Lei
Currently, we get an empty unique key for Intersect and Minus if its all is
true.
{code:java}
// code placeholder
public Set getUniqueKeys(SetOp rel, RelMetadataQuery mq,
boolean ignoreNulls) {
if (!rel.all) {
return ImmutableSet.of(
ImmutableBitSet.range(rel.getRowType().getFieldCount()));
}
return ImmutableSet.of();
}
{code}
However, from the semantic of Intersect and Minus, we can get their unique keys
from its input even if its all is true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3910) Enhance ProjectJoinTransposeRule to support SemiJoin and AntiJoin
Chunwei Lei created CALCITE-3910: Summary: Enhance ProjectJoinTransposeRule to support SemiJoin and AntiJoin Key: CALCITE-3910 URL: https://issues.apache.org/jira/browse/CALCITE-3910 Project: Calcite Issue Type: Improvement Components: core Affects Versions: 1.22.0 Reporter: Chunwei Lei -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3909) RelMdMinRowCount doesn't take into account UNION DISTINCT
Chunwei Lei created CALCITE-3909: Summary: RelMdMinRowCount doesn't take into account UNION DISTINCT Key: CALCITE-3909 URL: https://issues.apache.org/jira/browse/CALCITE-3909 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.22.0 Reporter: Chunwei Lei Assignee: Chunwei Lei -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3890) Infer IS NOT NULL predicate from join
Chunwei Lei created CALCITE-3890:
Summary: Infer IS NOT NULL predicate from join
Key: CALCITE-3890
URL: https://issues.apache.org/jira/browse/CALCITE-3890
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Chunwei Lei
We can infer IS NOT NULL predicate from join which implies some columns may not
be null. For instance,
{code:java}
select * from a join b on a.id = b.id;
{code}
we can infer a.id is not null and b.id is not null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3852) RexSimplify doesn't simplify NOT EQUAL predicates
Chunwei Lei created CALCITE-3852: Summary: RexSimplify doesn't simplify NOT EQUAL predicates Key: CALCITE-3852 URL: https://issues.apache.org/jira/browse/CALCITE-3852 Project: Calcite Issue Type: Improvement Components: core Reporter: Chunwei Lei Assignee: Chunwei Lei Given x=9, RexSimplify does not simplify x != 9 to false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3845) CASE WHEN expression with nullability CAST is considered as reduced wrongly in ReduceExpressionsRule
Chunwei Lei created CALCITE-3845:
Summary: CASE WHEN expression with nullability CAST is considered
as reduced wrongly in ReduceExpressionsRule
Key: CALCITE-3845
URL: https://issues.apache.org/jira/browse/CALCITE-3845
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Chunwei Lei
Assignee: Chunwei Lei
After ReduceExpressionsRule#reduceExpressionsInternal()[1],
{code:java}
CAST(CASE WHEN x then true WHEN y then TRUE ELSE false): boolean nullable
(exp1)
{code}
will be changed to
{code:java}
WHEN x then CAST(true): boolean nullable WHEN y then CAST(true): boolean
nullable ELSE CAST(false): boolean nullable. (exp2){code}
Then exp1 is considered as reduced. In the next step, by
ReduceExpressionsRule#simplifyPreservingType()[2], exp2 will be changed to
{code:java}
CAST(CASE WHEN x then true WHEN y then TRUE ELSE false): boolean nullable (exp3)
{code}
, which is exactly the same as exp1.
Though exp1 is actually not reduced, it is still considered as reduced[3],
which leads to CannotPlanException because of setImportance(project, 0.0)[4].
[1][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L618]
[2][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L624]
[3][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L303]
[4][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L312]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3838) Support Calc in RelMdSize,RelMdSelectivity,RelMdMaxRowCount,RelMdMinRowCount,RelMdTableReferences
Chunwei Lei created CALCITE-3838: Summary: Support Calc in RelMdSize,RelMdSelectivity,RelMdMaxRowCount,RelMdMinRowCount,RelMdTableReferences Key: CALCITE-3838 URL: https://issues.apache.org/jira/browse/CALCITE-3838 Project: Calcite Issue Type: Improvement Components: core Reporter: Chunwei Lei Assignee: Chunwei Lei -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3817) VolcanoPlanner does not remove the entry in ruleNames when removing a rule
Chunwei Lei created CALCITE-3817: Summary: VolcanoPlanner does not remove the entry in ruleNames when removing a rule Key: CALCITE-3817 URL: https://issues.apache.org/jira/browse/CALCITE-3817 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.21.0 Reporter: Chunwei Lei Assignee: Chunwei Lei VolcanoPlanner does not remove the entry in ruleNames when removing a rule[1]. [1][https://github.com/chunweilei/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/volcano/VolcanoPlanner.java#L490-L513] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3809) RexSimplify simplifies nondeterministic function incorrectly
Chunwei Lei created CALCITE-3809:
Summary: RexSimplify simplifies nondeterministic function
incorrectly
Key: CALCITE-3809
URL: https://issues.apache.org/jira/browse/CALCITE-3809
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Reporter: Chunwei Lei
Assignee: Chunwei Lei
Fix For: 1.22.0
For example, {{rand() = rand()}} will be simplified it to {{IS NOT
NULL(rand())}}, which is wrong because {{rand() = rand()}} might be false while
{{IS NOT NULL(rand())}} is always true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3803) Enhance RexSimplify to simplify 'a>1 or (a<3 and b)' to 'a>1 or b' if column a is not nullable
Chunwei Lei created CALCITE-3803:
Summary: Enhance RexSimplify to simplify 'a>1 or (a<3 and b)' to
'a>1 or b' if column a is not nullable
Key: CALCITE-3803
URL: https://issues.apache.org/jira/browse/CALCITE-3803
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Chunwei Lei
Assignee: Chunwei Lei
For {{a>1 or (a<3 and b)}}, with short-circuit, we know {{a<=1}} if {{a>1}} is
false when column a is not nullable. Then {{(a<3 and b) }}can be simplified to
{{b}}. Thus, {{a>1 or (a<3 and b) }}is simplified to {{a>1 or b.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3794) Return directly if there is no pulled up predicate
Chunwei Lei created CALCITE-3794:
Summary: Return directly if there is no pulled up predicate
Key: CALCITE-3794
URL: https://issues.apache.org/jira/browse/CALCITE-3794
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.21.0
Reporter: Chunwei Lei
Assignee: Chunwei Lei
Fix For: 1.22.0
If there is no pulled up predicates, it can not simplify anything in
{{simplifyUsingPredicates}}[1]. So it'd better return directly to reduce
overhead.
[1][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1572-L1586]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3791) HepPlanner does't clear metadata cache for the ancestors of discarded node when a transformation happens
Chunwei Lei created CALCITE-3791: Summary: HepPlanner does't clear metadata cache for the ancestors of discarded node when a transformation happens Key: CALCITE-3791 URL: https://issues.apache.org/jira/browse/CALCITE-3791 Project: Calcite Issue Type: Bug Components: core Reporter: Chunwei Lei Assignee: Chunwei Lei In HepPlanner, when a transformation happens, it will clear metadata cache for the parent of the discarded node[1]. But it doesn't clear the metadata cache for the ancestors of the parent. For example, assume we get a logical plan like A \ B \ C , if we clear the metadata cache for C after applying a rule, we should also clear the metadata cache for A and B since metadata of A and B derive from C. [1][https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/hep/HepPlanner.java#L877] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3630) Improve ReduceExpressionsRule
Chunwei Lei created CALCITE-3630:
Summary: Improve ReduceExpressionsRule
Key: CALCITE-3630
URL: https://issues.apache.org/jira/browse/CALCITE-3630
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Reporter: Chunwei Lei
Assignee: Chunwei Lei
In {{FilterReduceExpressionsRule}}, if the expression is a IS [NOT] NULL on a
non-nullable column, then we can either remove the filter or replace it with an
Empty(namely {{reduceNotNullableFilter}}). In such a case, we can set
importance to 0 to reduce search space.
{code:java}
// code placeholder
private void reduceNotNullableFilter(
RelOptRuleCall call,
Filter filter,
RexNode rexNode,
boolean reverse) {
// If the expression is a IS [NOT] NULL on a non-nullable
// column, then we can either remove the filter or replace
// it with an Empty.
boolean alwaysTrue;
switch (rexNode.getKind()) {
case IS_NULL:
case IS_UNKNOWN:
alwaysTrue = false;
break;
case IS_NOT_NULL:
alwaysTrue = true;
break;
default:
return;
}
if (reverse) {
alwaysTrue = !alwaysTrue;
}
RexNode operand = ((RexCall) rexNode).getOperands().get(0);
if (operand instanceof RexInputRef) {
RexInputRef inputRef = (RexInputRef) operand;
if (!inputRef.getType().isNullable()) {
if (alwaysTrue) {
call.transformTo(filter.getInput());
} else {
call.transformTo(createEmptyRelOrEquivalent(call, filter));
}
// New plan is absolutely better than old plan.
call.getPlanner().setImportance(filter, 0.0);
}
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3599) Initial the digest of RexRangeRef to avoid null string
Chunwei Lei created CALCITE-3599:
Summary: Initial the digest of RexRangeRef to avoid null string
Key: CALCITE-3599
URL: https://issues.apache.org/jira/browse/CALCITE-3599
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Chunwei Lei
Assignee: Chunwei Lei
Attachments: image-2019-12-12-23-49-18-977.png
Currently, the digest of {{RexRangeRef}} is always {{null}} which is confusing
when we try to debug the code. I suggest changing it to a more meaningful
string such as {{offset(0)}}.
!image-2019-12-12-23-49-18-977.png|width=529,height=234!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3569) IndexOutOfBoundsException when pushing FALSE filter to view
Chunwei Lei created CALCITE-3569:
Summary: IndexOutOfBoundsException when pushing FALSE filter to
view
Key: CALCITE-3569
URL: https://issues.apache.org/jira/browse/CALCITE-3569
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.21.0
Reporter: Chunwei Lei
Assignee: Chunwei Lei
It can be reproduced by the following test.
{code:java}
// MaterializationTest.java
@Test public void testAggregate7() {
try (TryThreadLocal.Memo ignored = Prepare.THREAD_TRIM.push(true)) {
MaterializationService.setThreadLocal();
CalciteAssert.that()
.withMaterializations(
HR_FKUK_MODEL,
"m0",
"select 11 as \"empno\", 22 as \"sal\", count(*) from \"emps\"
group by 11, 22")
.query(
"select * from\n"
+ "(select 11 as \"empno\", 22 as \"sal\", count(*)\n"
+ "from \"emps\" group by 11, 22) tmp\n"
+ "where \"sal\" = 33")
.enableMaterializations(true)
.explainContains("EnumerableValues(tuples=[[]])");
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3544) RexSimplify does not simpilfy RexNode completely
Chunwei Lei created CALCITE-3544:
Summary: RexSimplify does not simpilfy RexNode completely
Key: CALCITE-3544
URL: https://issues.apache.org/jira/browse/CALCITE-3544
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.21.0
Reporter: Chunwei Lei
Assignee: Chunwei Lei
When there are multiple predicates in RexSimplify, only the first predicates
will be used to simplify the RexNode. The following test can reproduce.
{code:java}
// code placeholder
@Test public void testSimplifyRangeWithMultiPredicates() {
RelDataType type = typeFactory.createSqlType(SqlTypeName.INTEGER);
final RexLiteral c1 = rexBuilder.makeExactLiteral(BigDecimal.ONE);
final RexLiteral c5 = rexBuilder.makeExactLiteral(BigDecimal.valueOf(5L));
final RexLiteral c9 = rexBuilder.makeExactLiteral(BigDecimal.valueOf(9L));
final RexNode ref = rexBuilder.makeInputRef(type, 1);
final RexNode pred1 = rexBuilder.makeCall(SqlStdOperatorTable.GREATER_THAN,
ref, c1);
final RexNode pred2 = rexBuilder.makeCall(SqlStdOperatorTable.LESS_THAN, ref,
c5);
List predicates = new ArrayList<>();
predicates.add(pred1);
predicates.add(pred2);
RelOptPredicateList relOptPredicateList = RelOptPredicateList.of(rexBuilder,
predicates);
RexNode node = rexBuilder.makeCall(SqlStdOperatorTable.GREATER_THAN, ref, c9);
final RexSimplify simplify =
new RexSimplify(rexBuilder, relOptPredicateList, RexUtil.EXECUTOR)
.withParanoid(true);
node = simplify.simplify(node);
assertThat(node, is(falseLiteral));
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3229) UnsupportedOperationException for UPDATE with IN query
Chunwei Lei created CALCITE-3229: Summary: UnsupportedOperationException for UPDATE with IN query Key: CALCITE-3229 URL: https://issues.apache.org/jira/browse/CALCITE-3229 Project: Calcite Issue Type: Bug Reporter: Chunwei Lei Query 2- "UPDATE tblspace1.table1 set n1=1000" + "WHERE k1 in (SELECT fk FROM tblspace1.table2 WHERE k2=?)" java.lang.UnsupportedOperationException: class org.apache.calcite.sql.SqlBasicCall: `K1` IN (SELECT `table2`.`fk` AS `FK` FROM `tblspace1`.`table2` AS `TABLE2` WHERE `table2`.`k2` = ?) at org.apache.calcite.util.Util.needToImplement(Util.java:967) at org.apache.calcite.sql.validate.SqlValidatorImpl.getValidatedNodeType(SqlValidatorImpl.java:1579) at org.apache.calcite.sql2rel.SqlToRelConverter.findSubQueries(SqlToRelConverter.java:1802) at org.apache.calcite.sql2rel.SqlToRelConverter.findSubQueries(SqlToRelConverter.java:1776) at org.apache.calcite.sql2rel.SqlToRelConverter.replaceSubQueries(SqlToRelConverter.java:1011) at org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:3570) at org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3172) at org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:563) at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:254) >From the thread >[https://lists.apache.org/thread.html/67cb614ddd123a9092fdf37ace279eb563838b045a5554ad0005f030@%3Cdev.calcite.apache.org%3E] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (CALCITE-3228) Error while applying rule ProjectScanRule: interpreter
Chunwei Lei created CALCITE-3228:
Summary: Error while applying rule ProjectScanRule: interpreter
Key: CALCITE-3228
URL: https://issues.apache.org/jira/browse/CALCITE-3228
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Chunwei Lei
The following test can reproduce the issue.
{code:java}
// FrameworksTest.java
@Test public void testMinMax() throws Exception {
Table table = new TableImpl();
final SchemaPlus rootSchema = Frameworks.createRootSchema(true);
SchemaPlus schema = rootSchema.add("x", new AbstractSchema());
schema.add("MYTABLE", table);
List traitDefs = new ArrayList<>();
traitDefs.add(ConventionTraitDef.INSTANCE);
traitDefs.add(RelDistributionTraitDef.INSTANCE);
SqlParser.Config parserConfig =
SqlParser.configBuilder(SqlParser.Config.DEFAULT)
.setCaseSensitive(false)
.build();
final FrameworkConfig config = Frameworks.newConfigBuilder()
.parserConfig(parserConfig)
.defaultSchema(schema)
.traitDefs(traitDefs)
// define the rules you want to apply
.ruleSets(
RuleSets.ofList(AbstractConverter.ExpandConversionRule.INSTANCE,
ProjectTableScanRule.INSTANCE))
.programs(Programs.ofRules(Programs.RULE_SET))
.build();
executeQuery(config, " select min(id) as mi, max(id) as ma from mytable where
id=1 group by id",
CalciteSystemProperty.DEBUG.value());
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3068) testSubprogram() does't test whether subprogram gets re-executed
Chunwei Lei created CALCITE-3068:
Summary: testSubprogram() does't test whether subprogram gets
re-executed
Key: CALCITE-3068
URL: https://issues.apache.org/jira/browse/CALCITE-3068
Project: Calcite
Issue Type: Bug
Affects Versions: 1.19.0
Reporter: Chunwei Lei
Assignee: Chunwei Lei
The goal of {{HepPlannerTest#testSubprogram}} is to test whether subprogram
gets re-executed. Unfortunately, it is unable to test it since there is only
one project and only fire the rule once.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-3015) Add rule to remove constants in group keys
Chunwei Lei created CALCITE-3015:
Summary: Add rule to remove constants in group keys
Key: CALCITE-3015
URL: https://issues.apache.org/jira/browse/CALCITE-3015
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
Assignee: Chunwei Lei
Constants in group keys can be removed to reduce shuffle. For instance,
{code:java}
select key, count(*) from (select 1 as key from src) dual group by key;
{code}
can be reduced to
{code:java}
select count(*) from (select 1 as key from src) dual;{code}
It could save much resource in distribute system if all group keys are
constants since the distribution becomes {{SINGLETON}} instead of {{HASH}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-3009) It should fail if there are duplicate keys in a .xml file
Chunwei Lei created CALCITE-3009:
Summary: It should fail if there are duplicate keys in a .xml file
Key: CALCITE-3009
URL: https://issues.apache.org/jira/browse/CALCITE-3009
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.19.0
Reporter: Chunwei Lei
Assignee: Chunwei Lei
There are duplicate keys for {{testProjectCorrelateTranspose}} in
RelOptRulesTest.xml[1][2]. We should add a test to make it fail when having
duplicate keys in a {{.xml}} file.
[1]
[https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L9226]
[2]
[https://github.com/apache/calcite/blob/master/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml#L9253]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2998) RexCopier should support all rex types
Chunwei Lei created CALCITE-2998:
Summary: RexCopier should support all rex types
Key: CALCITE-2998
URL: https://issues.apache.org/jira/browse/CALCITE-2998
Project: Calcite
Issue Type: Improvement
Reporter: Chunwei Lei
Assignee: Chunwei Lei
RexCopier don't support some rex types such as RexOver, RexDynamicParam and so
on as follows.
//RexCopier.java
public RexNode visitOver(RexOver over) {
{color:#FF} throw new UnsupportedOperationException();{color}
}
public RexWindow visitWindow(RexWindow window) {
{color:#FF} throw new UnsupportedOperationException();{color}
}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2965) Implement string functions: REPEAT, SPACE, SOUNDEX, DIFFERENCE
Chunwei Lei created CALCITE-2965: Summary: Implement string functions: REPEAT, SPACE, SOUNDEX, DIFFERENCE Key: CALCITE-2965 URL: https://issues.apache.org/jira/browse/CALCITE-2965 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.19.0 Reporter: Chunwei Lei Assignee: Chunwei Lei Fix For: 1.20.0 Some string functions including REPEAT, SPACE, SOUNDEX, DIFFERENCE are not implemented now. It would be great if these functions can be implemented. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2908) Add LAST_DAY function
Chunwei Lei created CALCITE-2908: Summary: Add LAST_DAY function Key: CALCITE-2908 URL: https://issues.apache.org/jira/browse/CALCITE-2908 Project: Calcite Issue Type: Bug Components: core Reporter: Chunwei Lei It would be nice if Calcite can support LAST_DAY function as Oracle/MySql does. [1] http://www.mysqltutorial.org/mysql-last_day/ [2] https://docs.oracle.com/cd/B19306_01/server.102/b14200/functions072.htm -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2896) RelBuilder supports creating TableFunctionScan
Chunwei Lei created CALCITE-2896: Summary: RelBuilder supports creating TableFunctionScan Key: CALCITE-2896 URL: https://issues.apache.org/jira/browse/CALCITE-2896 Project: Calcite Issue Type: Bug Components: core Reporter: Chunwei Lei Assignee: Chunwei Lei RelBuilder does not support TableFunctionScan yet. It is convenient and useful if RelBuilder can support creating TableFunctionScan just like other RelNode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2895) Some arguments are undocumented in constructor of LogicalAggregate
Chunwei Lei created CALCITE-2895:
Summary: Some arguments are undocumented in constructor of
LogicalAggregate
Key: CALCITE-2895
URL: https://issues.apache.org/jira/browse/CALCITE-2895
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Chunwei Lei
There are some undocumented arguments in constructor of LogicalAggregate,
including traitSet and indicator.
{code:java}
/**
* Creates a LogicalAggregate.
*
* Use {@link #create} unless you know what you're doing.
*
* @param cluster Cluster that this relational expression belongs to
* @param childinput relational expression
* @param groupSet Bit set of grouping fields
* @param groupSets Grouping sets, or null to use just {@code groupSet}
* @param aggCalls Array of aggregates to compute, not null
*/
public LogicalAggregate(
RelOptCluster cluster,
RelTraitSet traitSet,
RelNode child,
boolean indicator,
ImmutableBitSet groupSet,
List groupSets,
List aggCalls) {
super(cluster, traitSet, child, indicator, groupSet, groupSets, aggCalls);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2875) Some misspellings in RelOptListener
Chunwei Lei created CALCITE-2875:
Summary: Some misspellings in RelOptListener
Key: CALCITE-2875
URL: https://issues.apache.org/jira/browse/CALCITE-2875
Project: Calcite
Issue Type: Bug
Reporter: Chunwei Lei
Assignee: Chunwei Lei
There are some misspellings in RelOptListener:
{code:java}
/**
* Notifies this listener that a relational expression has been chosen as
* part of the final implementation of the query plan. After the plan is
* {color:red}copmlete{color}, this is called one more time with null for the
rel.
*
* @param event details about the event
*/
void relChosen(RelChosenEvent event);
/** Event indicating that a planner rule has been
{color:red}attemptedd{color}. */
class RuleAttemptedEvent extends RuleEvent {
private final boolean before;
public RuleAttemptedEvent(
Object eventSource,
RelNode rel,
RelOptRuleCall ruleCall,
boolean before) {
super(eventSource, rel, ruleCall);
this.before = before;
}
public boolean isBefore() {
return before;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2729) Introducing WindowExpressionRules
Chunwei Lei created CALCITE-2729: Summary: Introducing WindowExpressionRules Key: CALCITE-2729 URL: https://issues.apache.org/jira/browse/CALCITE-2729 Project: Calcite Issue Type: Bug Affects Versions: 1.17.0 Reporter: Chunwei Lei Assignee: Chunwei Lei Fix For: 1.18.0 Introducing WindowExpressionRules -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2661) support creating Exchange and SortExchange in RelBuilder
Chunwei Lei created CALCITE-2661: Summary: support creating Exchange and SortExchange in RelBuilder Key: CALCITE-2661 URL: https://issues.apache.org/jira/browse/CALCITE-2661 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.17.0 Reporter: Chunwei Lei Assignee: Julian Hyde Fix For: 1.18.0 It is useful if RelBuilder can support creating Exchange and SortExchange just like other RelNode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2658) Introducing more ReduceExpressionRules
Chunwei Lei created CALCITE-2658: Summary: Introducing more ReduceExpressionRules Key: CALCITE-2658 URL: https://issues.apache.org/jira/browse/CALCITE-2658 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.17.0 Reporter: Chunwei Lei Assignee: Julian Hyde Fix For: 1.18.0 It is useful to have rules reducing Exchange/Sort/SortExchange keys, e.g., SELECT key,value FROM (SELECT 1 AS key, value FROM src) r DISTRIBUTE BY key; can be reduced to SELECT 1 AS key, value FROM src;# Since singleton requirement may already required by SELECT. SELECT key,value FROM (SELECT 1 AS key, value FROM src) r ORDER BY key; can be reduced to SELECT 1 AS key, value FROM src;# Since ordering on constant is useless. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2657) use RexCall#clone instead of constructor to make a new RexCall in RexShuttle for more scalability
Chunwei Lei created CALCITE-2657:
Summary: use RexCall#clone instead of constructor to make a new
RexCall in RexShuttle for more scalability
Key: CALCITE-2657
URL: https://issues.apache.org/jira/browse/CALCITE-2657
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.17.0
Reporter: Chunwei Lei
Assignee: Julian Hyde
Fix For: 1.18.0
RexShuttle uses constructor of RexCall to generate a new RexCall, as followings:
{code:java}
public RexNode visitCall(final RexCall call) {
boolean[] update = {false};
List clonedOperands = visitList(call.operands, update);
if (update[0]) {
// REVIEW jvs 8-Mar-2005: This doesn't take into account
// the fact that a rewrite may have changed the result type.
// To do that, we would need to take a RexBuilder and
// watch out for special operators like CAST and NEW where
// the type is embedded in the original call.
return new RexCall(
call.getType(),
call.getOperator(),
clonedOperands);
} else {
return call;
}
}
{code}
It is more scalability when using RexCall#clone() for those using sub-class of
RexCall since function clone can be overwrite by sub-class, as followings:
{code:java}
public RexNode visitCall(final RexCall call) {
boolean[] update = {false};
List clonedOperands = visitList(call.operands, update);
if (update[0]) {
// REVIEW jvs 8-Mar-2005: This doesn't take into account
// the fact that a rewrite may have changed the result type.
// To do that, we would need to take a RexBuilder and
// watch out for special operators like CAST and NEW where
// the type is embedded in the original call.
return call.clone(call.getType(), clonedOperands);
} else {
return call;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
