Calcite-Master - Build # 283 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #283)

Status: Still Failing

Check console output at https://builds.apache.org/job/Calcite-Master/283/ to 
view the results.

Releases

[Julian Hyde]

When should we release Calcite 1.17? When should we release Avatica 1.12? 
Anyone volunteer to be release manager?

Because of https://issues.apache.org/jira/browse/CALCITE-2303 
, we need to release 
Avatica before Calcite.

I have logged https://issues.apache.org/jira/browse/CALCITE-2330 
 to track Avatica 1.12.

Julian

[jira] [Created] (CALCITE-2330) Release Avatica 1.12

[Julian Hyde (JIRA)]

Julian Hyde created CALCITE-2330:


 Summary: Release Avatica 1.12
 Key: CALCITE-2330
 URL: https://issues.apache.org/jira/browse/CALCITE-2330
 Project: Calcite
  Issue Type: Bug
  Components: avatica
Reporter: Julian Hyde


Release Avatica 1.12.

We currently have no estimated release date; last release (1.11) was March 2018 
and the one before (1.10) that was May 2017.



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

Calcite-Master - Build # 282 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #282)

Status: Still Failing

Check console output at https://builds.apache.org/job/Calcite-Master/282/ to 
view the results.

[jira] [Created] (CALCITE-2329) Enhance SubQueryRemoveRule to rewrite IN operator with the constant from the left side more optimally

[Volodymyr Vysotskyi (JIRA)]

Volodymyr Vysotskyi created CALCITE-2329:


 Summary: Enhance SubQueryRemoveRule to rewrite IN operator with 
the constant from the left side more optimally
 Key: CALCITE-2329
 URL: https://issues.apache.org/jira/browse/CALCITE-2329
 Project: Calcite
  Issue Type: Improvement
Reporter: Volodymyr Vysotskyi
Assignee: Julian Hyde


Currently, for queries like this:
{code:sql}
select sal from emp where 2 IN (select deptno from dept)
{code}
SubQueryRemoveRule rules expand query plan in such a way:
{noformat}
LogicalProject(SAL=[$5])
  LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
LogicalJoin(condition=[=(2, $9)], joinType=[inner])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
  LogicalProject(DEPTNO=[$0])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{noformat}
Since join condition is actually a filter condition, it will be pushed into the 
filter during further planning stages and join with the true condition is left.

But these types of the queries may be rewritten in the same way as EXISTS 
queries:
{code:sql}
select sal from emp where EXISTS (select deptno from dept where deptno=2)
{code}
with the more optimal plan:
{noformat}
LogicalProject(SAL=[$5])
  LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
LogicalJoin(condition=[true], joinType=[inner])
  LogicalTableScan(table=[[CATALOG, SALES, EMP]])
  LogicalAggregate(group=[{0}])
LogicalProject(i=[true])
  LogicalFilter(condition=[=($0, 2)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{noformat}



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

[jira] [Created] (CALCITE-2328) Operand of Logical And/OR should support type like INT, DOUTLE not only boolean

[yuqi (JIRA)]

yuqi created CALCITE-2328:
-

 Summary: Operand of Logical And/OR should support type like INT, 
DOUTLE not only boolean
 Key: CALCITE-2328
 URL: https://issues.apache.org/jira/browse/CALCITE-2328
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.16.0
Reporter: yuqi
Assignee: Julian Hyde
 Fix For: 1.17.0


As far as i see , MySQL support the following sql

{code:java}
select id, name from tb where 1 and 1;
select id, name from tb where 1 and true;

{code}

However, calcite would not recognize that sql and says:
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Cannot apply 
'AND' to arguments of type ' AND '. Supported form(s): 
' AND '
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 27 more

So, I propose if we should introduce more type support for logical AND/OR




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