[jira] [Created] (CALCITE-4150) RelToSqlConverter does not support null without a cast: "Unsupported type when convertTypeToSpec: NULL"

[Anton Haidai (Jira)]

Anton Haidai created CALCITE-4150:
-

 Summary: RelToSqlConverter does not support null without a cast: 
"Unsupported type when convertTypeToSpec: NULL"
 Key: CALCITE-4150
 URL: https://issues.apache.org/jira/browse/CALCITE-4150
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.24.0
Reporter: Anton Haidai


RelToSqlConverterTest:
{code:java}
 @Test void testSelectNullNoCast() {
  String query = "select \"product_id\", null as dummy from \"product\"";
  final String expected = "SELECT \"product_id\", CAST(NULL AS NULL) AS 
\"DUMMY\"\n"
  + "FROM \"foodmart\".\"product\"";
  sql(query).ok(expected);
}{code}
the test works fine in 1.23.

result in 1.24:
{code:java}
Unsupported type when convertTypeToSpec: NULL
Unsupported type when convertTypeToSpec: NULL
java.lang.UnsupportedOperationException: Unsupported type when 
convertTypeToSpec: NULL at 
org.apache.calcite.sql.type.SqlTypeUtil.convertTypeToSpec(SqlTypeUtil.java:1078)
 at org.apache.calcite.sql.SqlDialect.getCastSpec(SqlDialect.java:790) at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.castNullType(RelToSqlConverter.java:361)
 at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:342)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method) at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:566) at 
org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:524) at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:131){code}
Please note, that there is an existing test "testSelectNull()", but it tests 
nulls with cast, "CAST(NULL AS INT)".



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

[jira] [Created] (CALCITE-4029) ProjectRemoveRule auto pruning may prevent rules from running if mixed conventions are used in a logical plan

[Anton Haidai (Jira)]

Anton Haidai created CALCITE-4029:
-

 Summary: ProjectRemoveRule auto pruning may prevent rules from 
running if mixed conventions are used in a logical plan 
 Key: CALCITE-4029
 URL: https://issues.apache.org/jira/browse/CALCITE-4029
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.23.0
Reporter: Anton Haidai


Preconditions to reproduce the issue:
 # Logical plan has mixed conventions (for example, a bottom node is a 
TableScan in a final convention while other nodes are regular logical nodes 
with NONE convention).
 # There is a rule that expects a logical node with an input (like a rule 
matching "operand(LogicalSort.class, operand(RelNode.class, any()))")
 # A project over the scan is trivial (like SELECT * FROM ...)

The issue is related to https://issues.apache.org/jira/browse/CALCITE-3939, 
please see comments regarding a detailed debugging of a real-life reproducing 
case.
h4. Example:

Logical plan with a leaf nodes in a custom convention:
LogicalSort[NONE]
  LogicalProject[NONE]
CustomScan[CUSTOM_CONVENTION]
A rule configured (RuleX) matches "operand(LogicalSort.class, 
operand(RelNode.class, any()))".

*Without ProjectRemoveRule auto pruning*

ProjectRemoveRule recognizes LogicalProject as trivial an merges it into a 
single RelSet with CustomScan. 

RuleX can run on top of this change as far as LogicalProject has a logical node 
(LogicalProject in RelSubset[NONE]) as an input.

 

*With ProjectRemoveRule auto pruning*

ProjectRemoveRule recognizes LogicalProject as trivial but removes with it's 
RelSet so the CustomScan is the only node in it's RelSet, 
RelSubset[CUSTOM_CONVENTION].

RuleX can't run on top of this change as far as LogicalProject has an empty 
input RelSubset[NONE] of the RelSet with the CustomScan.
h2. Possible workarounds
 # Disable ProjectRemoveRule auto pruning.
 # Use only logical nodes in a logical plan, for the example above: use 
LogicalScan - >  CustomScanRule - > CustomScan instead of direct use of 
CustomScan.



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

[jira] [Created] (CALCITE-3839) Can't get group field by name: "field [ENAME] not found;"

[Anton Haidai (Jira)]

Anton Haidai created CALCITE-3839:
-

 Summary: Can't get group field by name: "field [ENAME] not found;"
 Key: CALCITE-3839
 URL: https://issues.apache.org/jira/browse/CALCITE-3839
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.22.0
Reporter: Anton Haidai


The regression is spotted in 1.22.0 RC 3. The test works fine in 1.21.0 branch.
RelBuilderTest:
{code}
  @Test public void testGetGroupFieldByName() {
  final Function f = builder -> {
  RelBuilder aggregated = builder.scan("EMP")
  .project(builder.field("EMPNO"), builder.field("ENAME"), 
builder.field("SAL"))
  .aggregate(
  builder.groupKey(builder.field("ENAME")),
  builder.sum(builder.field("SAL"))
  );
  RexInputRef groupFieldReference = aggregated.field("ENAME");
  assertThat(groupFieldReference.getIndex(), is(0));
  return aggregated.build();
  };

  final String expected =
  "LogicalAggregate(group=[{1}], agg#0=[SUM($2)])\n" +
  "  LogicalProject(EMPNO=[$0], ENAME=[$1], SAL=[$5])\n" +
  "LogicalTableScan(table=[[scott, EMP]])\n";
  assertThat(f.apply(createBuilder(c -> c)), hasTree(expected));
  }
{code}

Error (1.22.0 RC 3): 
{code}
field [ENAME] not found; input fields are: [EMPNO, $f1]
java.lang.IllegalArgumentException: field [ENAME] not found; input fields are: 
[EMPNO, $f1]
at org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:402)
at org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:385)
at 
org.apache.calcite.test.RelBuilderTest.lambda$testGetGroupFieldByName$15(RelBuilderTest.java:990)
at 
org.apache.calcite.test.RelBuilderTest.testGetGroupFieldByName(RelBuilderTest.java:999)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}



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

[jira] [Created] (CALCITE-3675) SQL to Rel conversion is broken for coalesce on nullable field

[Anton Haidai (Jira)]

Anton Haidai created CALCITE-3675:
-

 Summary: SQL to Rel conversion is broken for coalesce on nullable 
field
 Key: CALCITE-3675
 URL: https://issues.apache.org/jira/browse/CALCITE-3675
 Project: Calcite
  Issue Type: Bug
Affects Versions: next
Reporter: Anton Haidai


Reproducible in master (06ac187a342f82a4b69e4c752ccdce0c269a350d): 
1.22.0-SNAPSHOT

SqlToRelConverterTest:
{code}
  @Test public void testCoalesceOnNullableField() {
final String sql = "select coalesce(mgr, 0) from emp";
sql(sql).ok();
  }
{code}

Error:
{code}
Conversion to relational algebra failed to preserve datatypes:
validated type:
RecordType(INTEGER NOT NULL EXPR$0) NOT NULL
converted type:
RecordType(INTEGER EXPR$0) NOT NULL
rel:
LogicalProject(EXPR$0=[CASE(IS NOT NULL($3), $3, 0)])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}



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

[jira] [Created] (CALCITE-3537) Can't apply materialized view with a simple filter

[Anton Haidai (Jira)]

Anton Haidai created CALCITE-3537:
-

 Summary: Can't apply materialized view with a simple filter
 Key: CALCITE-3537
 URL: https://issues.apache.org/jira/browse/CALCITE-3537
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.21.0
Reporter: Anton Haidai


The issue is reproducible in MaterializationTest:
{code}
  @Test public void testMvPredicate() {
  CalciteAssert.that()
  .withMaterializations(
  HR_FKUK_MODEL,
  "MyMv",
  "select \"deptno\", \"name\", \"empid\", count(*) from 
\"emps\" group by  \"name\", \"deptno\", \"empid\" "
  )
  .query([INSERT SQL HERE])
  .enableMaterializations(true)
  .explainContains("MyMv")
  .sameResultWithMaterializationsDisabled();
  }
{code}

"[INSERT SQL HERE]" can be substituted by the following SQLs:

*Case 1: simple filter over a non-group field.*
Result: Success.
{code}
"select \"name\", count(*) from \"emps\" where \"deptno\"= 10  group by 
\"name\" "
{code}

*Case 2: complex filter over group field.*
Result: Success.
{code}
"select \"name\", count(*) from \"emps\" where \"name\"= 'Sebastian' OR 
\"name\"= 'Peter'  group by \"name\" "
{code}

*Case 3: complex filter on group field*
Result: Fail
{code}
"select \"name\", count(*) from \"emps\" where \"name\"= 'Sebastian' group by 
\"name\" "
{code}
The simple filtering condition makes the materialized view unusable while it 
could be used just like in the *Case 2*:
{code}
java.lang.AssertionError: 
Expected: a string containing "MyMv"
 but: was "PLAN=EnumerableAggregate(group=[{2}], EXPR$1=[COUNT()])\n  
EnumerableCalc(expr#0..4=[{inputs}], expr#5=[CAST($t2):VARCHAR], 
expr#6=['Sebastian':VARCHAR], expr#7=[=($t5, $t6)], proj#0..4=[{exprs}], 
$condition=[$t7])\nEnumerableTableScan(table=[[hr, emps]])\n\n"
{code}

Looks like something is wrong with "compensationPreds" calculation in 
AbstractMaterializedViewRule.





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

[jira] [Created] (CALCITE-3364) Can't group table function result due to a type cast error

[Anton Haidai (Jira)]

Anton Haidai created CALCITE-3364:
-

 Summary: Can't group table function result due to a type cast error
 Key: CALCITE-3364
 URL: https://issues.apache.org/jira/browse/CALCITE-3364
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.21.0
Reporter: Anton Haidai


I was not able to find a suitable test, so I'll describe the issue using a 
custom minimal table function as example. I believe, that it should be 
reproducible against any table function.

There is a simple table function my_dummy() that just prints numbers 1 to 5. 
Simple select works as expected:
{code}
SQL:
select val from table(my_dummy())
Result:
val : INTEGER
5
4
3
2
1
{code}

However, when trying to make an aggregation on top of it, there is a class cast 
error:
{code}
SQL:
select val from table(my_dummy())
group by val

Error:
java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to 
java.lang.Integer
at 
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:541)
at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:340)
at 
org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:393)
{code}
Actually, this array Object[] contains a single integer produced by the table 
function. Also I faced similar class cast errors in a generated code making 
hashJoin.

Here is this my_dummy() table function implementation (single file):
{code}
package com.myapp.tf;

import org.apache.calcite.DataContext;
import org.apache.calcite.linq4j.AbstractEnumerable;
import org.apache.calcite.linq4j.Enumerable;
import org.apache.calcite.linq4j.Enumerator;
import org.apache.calcite.linq4j.tree.Types;
import org.apache.calcite.rel.type.RelDataType;
import org.apache.calcite.rel.type.RelDataTypeFactory;
import org.apache.calcite.schema.ScannableTable;
import org.apache.calcite.schema.TableFunction;
import org.apache.calcite.schema.impl.AbstractTable;
import org.apache.calcite.schema.impl.TableFunctionImpl;
import org.apache.calcite.sql.SqlIdentifier;
import org.apache.calcite.sql.SqlOperatorBinding;
import org.apache.calcite.sql.parser.SqlParserPos;
import org.apache.calcite.sql.type.SqlTypeName;
import org.apache.calcite.sql.validate.SqlUserDefinedTableFunction;
import java.util.Collections;
import java.util.concurrent.atomic.AtomicInteger;
import static org.apache.calcite.sql.type.OperandTypes.family;

public class DummyFunction extends SqlUserDefinedTableFunction {

public static String DUMMY_FUNCTION_NAME = "my_dummy";

public static final TableFunction DUMMY_TABLE_FUNCTION = 
TableFunctionImpl.create(Types.lookupMethod(
DummyFunction.class,
"createDummyTable"
));

public static DummyTable createDummyTable() {
return new DummyTable();
}

public DummyFunction() {
super(new SqlIdentifier(DUMMY_FUNCTION_NAME, SqlParserPos.ZERO),
null,
null,
family(),
Collections.emptyList(),
DUMMY_TABLE_FUNCTION
);
}

@Override
public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
RelDataTypeFactory typeFactory = opBinding.getTypeFactory();

return typeFactory.builder()
.add("val", SqlTypeName.INTEGER)
.build();
}
}

class DummyTable extends AbstractTable implements ScannableTable {

private final AtomicInteger cnt = new AtomicInteger(6);

@Override
public Enumerable scan(DataContext root) {
return new AbstractEnumerable() {
public Enumerator enumerator() {
return new Enumerator () {
@Override
public Object[] current() {
return new Object[] { cnt.intValue() };
}

@Override
public boolean moveNext() {
return cnt.decrementAndGet() > 0;
}

@Override
public void reset() {

}

@Override
public void close() {

}
};
}
};
}

@Override
public RelDataType getRowType(RelDataTypeFactory typeFactory) {
return typeFactory.builder()
.add("val", SqlTypeName.INTEGER)
.build();
}
}
{code}

And adding it into a schema:
{code}
mySchemaPlus.add(DUMMY_FUNCTION_NAME, DummyFunction.DUMMY_TABLE_FUNCTION);
{code}





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

[jira] [Created] (CALCITE-3354) RelToSqlConverter does not support LogicalTableFunctionScan

[Anton Haidai (Jira)]

Anton Haidai created CALCITE-3354:
-

 Summary: RelToSqlConverter does not support 
LogicalTableFunctionScan
 Key: CALCITE-3354
 URL: https://issues.apache.org/jira/browse/CALCITE-3354
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.21.0
Reporter: Anton Haidai


Here is the test in *RelBuilderTest* to reproduce the isse (the right place for 
this test is RelToSqlConverterTest, but it does not have test table functions 
configured):
{code}
  @Test
  public void testFailToConvertLogicalTableFunctionScanToSql() {
final RelBuilder builder = RelBuilder.create(config().build());
final SqlOperator rampFunction = new MockSqlOperatorTable.RampFunction();
RelNode root = builder.functionScan(rampFunction, 0, builder.literal(3))
.build();
toSql(root, CalciteSqlDialect.DEFAULT);
  }

  private static String toSql(RelNode root, SqlDialect dialect) {
final RelToSqlConverter converter = new RelToSqlConverter(dialect);
final SqlNode sqlNode = converter.visitChild(0, root).asStatement();
return sqlNode.toSqlString(dialect).getSql();
  }
{code}

Result: 
{code}
java.lang.RuntimeException: While invoking method 'public 
org.apache.calcite.rel.rel2sql.SqlImplementor$Result 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(org.apache.calcite.rel.RelNode)'

at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:527)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.dispatch(RelToSqlConverter.java:122)
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visitChild(RelToSqlConverter.java:128)
at org.apache.calcite.test.RelBuilderTest.toSql(RelBuilderTest.java:331)
at 
org.apache.calcite.test.RelBuilderTest.testFailToConvertLogicalTableFunctionScanToSql(RelBuilderTest.java:326)
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.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.reflect.InvocationTargetException
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.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:524)
... 26 more
Caused by: java.lang.AssertionError: Need to implement 
org.apache.calcite.rel.logical.LogicalTableFunctionScan
at 
org.apache.calcite.rel.rel2sql.RelToSqlConverter.visit(RelToSqlConverter.java:136)
... 31 more
{code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (CALCITE-3076) Error when AggregateJoinTransposeRule is used on empty LogicalValues

[Anton Haidai (JIRA)]

Anton Haidai created CALCITE-3076:
-

 Summary: Error when AggregateJoinTransposeRule is used on empty 
LogicalValues
 Key: CALCITE-3076
 URL: https://issues.apache.org/jira/browse/CALCITE-3076
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.19.0
Reporter: Anton Haidai


RelOptRulesTest:
{code}
  @Test public void testPushAggregateThroughJoinOnEmptyLogicalValuesError() {
final HepProgram preProgram = new HepProgramBuilder()
.addRuleInstance(AggregateProjectMergeRule.INSTANCE)

.addRuleInstance(ReduceExpressionsRule.FilterReduceExpressionsRule.FILTER_INSTANCE)
.build();

final HepProgram program = new HepProgramBuilder()
.addRuleInstance(AggregateJoinTransposeRule.EXTENDED)
.build();

final String sql =
"select count(*) volume, sum(C1.sal) C1_max_sal " +
"from (select sal, ename from sales.emp where 1=2) C1 " +
"inner join (select ename from sales.emp) C2   " +
"on C1.ename = C2.ename ";
sql(sql).withPre(preProgram).with(program).check();
  }
{code}

Error:
{code}
java.lang.IllegalArgumentException: Cannot infer return type for *; operand 
types: [VARCHAR(20), BIGINT]

at 
org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:474)
at 
org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:276)
at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:250)
at 
org.apache.calcite.sql.SqlSplittableAggFunction$AbstractSumSplitter.topSplit(SqlSplittableAggFunction.java:298)
at 
org.apache.calcite.rel.rules.AggregateJoinTransposeRule.onMatch(AggregateJoinTransposeRule.java:342)
at 
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:559)
at 
org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:418)
at 
org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:255)
at 
org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-3060) Materialized view: "target out of range" error

[Anton Haidai (JIRA)]

Anton Haidai created CALCITE-3060:
-

 Summary: Materialized view: "target out of range" error
 Key: CALCITE-3060
 URL: https://issues.apache.org/jira/browse/CALCITE-3060
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.19.0
Reporter: Anton Haidai


"MaterializationTest":
{code}
@Test public void testPremutationError() {
CalciteAssert.that()
.withMaterializations(
HR_FKUK_MODEL,
"m0",
"select min(\"salary\"), count(*), max(\"salary\"), 
sum(\"salary\"), \"empid\" from \"emps\" group by \"empid\"",
"m1",
"select min(\"salary\"), count(*), max(\"salary\"), 
sum(\"salary\"), \"deptno\", \"empid\" from \"emps\" group by \"empid\", 
\"deptno\""
)
.query(
"select count(*), \"empid\" from \"emps\" group by \"empid\"")
.enableMaterializations(true)
.explainContains("EnumerableTableScan(table=[[hr, m0]])")
.sameResultWithMaterializationsDisabled();
  }
{code}

Error (looks like the mapping is expected to be bijection but it is not):
{code}
Caused by: java.lang.IllegalArgumentException: target out of range
at org.apache.calcite.util.Permutation.(Permutation.java:69)
at org.apache.calcite.util.mapping.Mappings.bijection(Mappings.java:394)
at 
org.apache.calcite.rel.mutable.MutableRels.createProject(MutableRels.java:142)
at 
org.apache.calcite.plan.SubstitutionVisitor.unifyAggregates(SubstitutionVisitor.java:1269)
at 
org.apache.calcite.plan.SubstitutionVisitor$AggregateOnProjectToAggregateUnifyRule.apply(SubstitutionVisitor.java:1345)
at 
org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:531)
at 
org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:466) 

{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-3052) Error while applying rule MaterializedViewAggregateRule(Project-Aggregate): ArrayIndexOutOfBoundsException

[Anton Haidai (JIRA)]

Anton Haidai created CALCITE-3052:
-

 Summary: Error while applying rule 
MaterializedViewAggregateRule(Project-Aggregate): ArrayIndexOutOfBoundsException
 Key: CALCITE-3052
 URL: https://issues.apache.org/jira/browse/CALCITE-3052
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.19.0
Reporter: Anton Haidai


*Materialized views enabled:*
# "select avg(grade), count(*), max(grade), sum(grade), min(grade), team from 
students group by team"
# "select avg(grade), count(*), max(grade), sum(grade), min(grade), team, 
faculty from students group by faculty, team",

*Query:*
# "select count(*), team from students group by team"

*Error* (stacktrace is obtained using the current *master* branch: 
"247c7d4f76"):
{code}
at 
org.apache.calcite.prepare.ZEnginePreparingStmt.optimize(ZEnginePreparingStmt.java:311)
at 
org.apache.calcite.prepare.ZEnginePreparingStmt.prepare_(ZEnginePreparingStmt.java:195)
at 
org.apache.calcite.prepare.ZEnginePreparingStmt.prepareRel(ZEnginePreparingStmt.java:142)
at 
org.apache.calcite.prepare.ZEnginePrepareImpl.prepare2_(ZEnginePrepareImpl.java:424)
at 
org.apache.calcite.prepare.ZEnginePrepareImpl.prepareSql(ZEnginePrepareImpl.java:108)
... 55 common frames omitted
Caused by: java.lang.ArrayIndexOutOfBoundsException: 2
at 
com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
at org.apache.calcite.rex.RexBuilder.makeInputRef(RexBuilder.java:841)
at 
org.apache.calcite.rel.rules.AbstractMaterializedViewRule$MaterializedViewAggregateRule.rewriteView(AbstractMaterializedViewRule.java:1507)
at 
org.apache.calcite.rel.rules.AbstractMaterializedViewRule.perform(AbstractMaterializedViewRule.java:522)
at 
org.apache.calcite.rel.rules.AbstractMaterializedViewRule$MaterializedViewProjectAggregateRule.onMatch(AbstractMaterializedViewRule.java:1776)
at 
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
... 71 common frames omitted
{code}

Reproducible only if both Materialization views listed are enabled: any single 
one of these two could be successfully used with the query without any errors. 
Currently, I'm trying to reproduce the issue in "MaterializationTest": without 
a success so far, I'll update the ticket if I'll find a working way to 
reproduce the issue in the test will be discovered.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2666) JoinPushThroughJoinRule can't reach an optimal plan in some 3+ joins cases

[Anton Haidai (JIRA)]

Anton Haidai created CALCITE-2666:
-

 Summary: JoinPushThroughJoinRule can't reach an optimal plan in 
some 3+ joins cases
 Key: CALCITE-2666
 URL: https://issues.apache.org/jira/browse/CALCITE-2666
 Project: Calcite
  Issue Type: Bug
  Components: core
Reporter: Anton Haidai
Assignee: Julian Hyde
 Attachments: calcite.join.pushdown.issue.png

For example, the input query is the following:

 
{code:java}
SELECT *
FROM X
INNER JOIN A
ON X.id = A.id
INNER JOIN Y
ON X.id = Y.id
INNER JOIN Z
ON X.id = Z.id
{code}
According to the cost model used, it would be beneficial to push the "A" scan 
to the right node of the top join (grouping X, Y, Z scans in two bottom joins 
in any order). But this state is never reached, "A" scan could be pushed only 
one join up, but never two joins up.

 
h2. Cause

According to my debugging, the cause of the issue is the following.

As far as the optimal state could hypothetically be achieved only by 
JoinPushThroughJoinRule.RIGHT, lets review only the behavior of this rule (while

JoinPushThroughJoinRule.LEFT is also affected by the issue described). After 
each transformation, JoinPushThroughJoinRule.RIGHT not only swaps right nodes 
of joins, but also adds an additional project node on top of transformed joins.

The rule expects the following input structure:
{code:java}
operand(LogicalJoin.class,
operand(LogicalJoin.class, any()),
operand(RelNode.class, any())
)
{code}
But after applying the rule to two bottom joins, there will be an additional 
project between  these joins and the top join, so the middle join is no longer 
the left input of the top join and the rule can't match and produce the optimal 
result. See the attachment for a visual representation of this explanation:

!calcite.join.pushdown.issue.png!

 

 
h2.  

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2618) It is not possible to execute IN on Enumerable: "cannot translate call IN"

[Anton Haidai (JIRA)]

Anton Haidai created CALCITE-2618:
-

 Summary: It is not possible to execute IN on Enumerable: "cannot 
translate call IN"
 Key: CALCITE-2618
 URL: https://issues.apache.org/jira/browse/CALCITE-2618
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.17.0
Reporter: Anton Haidai
Assignee: Julian Hyde


It is not possible to execute IN on Enumerable.

Logical plan node:
{code:java}
LogicalFilter(condition=[IN($1, 'Aaron', 'Abbeville', 'Abbot')])
{code}
Physical plan node:
{code:java}
EnumerableCalc( ... expr#53=[IN($t0, $t3, $t4)])
{code}
Error message when trying to execute the plan:
{code:java}
Caused by: java.lang.RuntimeException: cannot translate call IN($t0, $t3, $t4)
at 
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCall(RexToLixTranslator.java:725)
at 
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:699)
at 
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:221)
...{code}
The issue occurs because "IN" is absent in RexImpTable.

It is not possible to reproduce the issue using SQL as far as INs in SQL 
queries are always replaced either by ORs, or by a subselect (see CALCITE-2444 
for a similar issue). But it is possible to reproduce the issue when creating a 
filter with "IN" using RelBuilder.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2616) Can't create Unicode literal by RelBuilder

[Anton Haidai (JIRA)]

Anton Haidai created CALCITE-2616:
-

 Summary: Can't create Unicode literal by RelBuilder
 Key: CALCITE-2616
 URL: https://issues.apache.org/jira/browse/CALCITE-2616
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.17.0
Reporter: Anton Haidai
Assignee: Julian Hyde


Test in RelBuilderTest to reproduce the issue:
{code:java}
@Test public void testScanWithFilterByUnicodeValue() {
  final RelBuilder builder = RelBuilder.create(config().build());
  RelNode root =
  builder.scan("EMP")
  .filter(
  builder.call(SqlStdOperatorTable.EQUALS,
  builder.field("ENAME"),
  builder.literal("Петро ピーター")
  )
  )
  .build();
}
{code}
 Result:

org.apache.calcite.runtime.CalciteException: Failed to encode 'Петро ピーター' in 
character set 'ISO-8859-1'

Possible workaround: create saffron.properties with the following property

saffron.default.charset=UTF-16LE

But UTF-8 will not work as a value of this property, see 
SqlUtil.translateCharacterSetName

Related code:
 * SqlUtil.translateCharacterSetName(charsetName)
 * RelDataTypeFactoryImpl.getDefaultCharset()
 * SaffronProperties

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)