??????[DISCUSS] State of the project 2020
Hi Stamatis, Thanks for your great work! Calcite is very good at semantic transformation of relational algebra. In the process of the project, users can optimize relational algebra by implementing RelOptRule or RelShuttle and so on, so as to bring relational algebra into physical query engine. Another point is the construction of materialized view recognition framework, which realizes the ability of materialized view recognition of common relational algebra. The expression of relational algebra is very flexible, and it can do better in identifying various materialized views. +1 for voting Haisheng. Best, Zhaohui Xu ---- ??: "dev" http://calcite.apache.org/news/2015/10/22/calcite-graduates/ [2] http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201509.mbox/%3CCF8D6F96-706F-4502-B41D-0689E357209D%40apache.org%3E [3] https://issues.apache.org/jira/browse/CALCITE-3923 [4] https://issues.apache.org/jira/browse/CALCITE-3724 [5] https://issues.apache.org/jira/browse/CALCITE-2157 [6] https://issues.apache.org/jira/browse/CALCITE-3916 [7] https://issues.apache.org/jira/browse/CALCITE-3896 [8] https://issues.apache.org/jira/browse/CALCITE-3753 [9] https://issues.apache.org/jira/browse/CALCITE-2970 [10] https://issues.apache.org/jira/browse/CALCITE-482 [11] https://issues.apache.org/jira/browse/CALCITE-3510 [12] https://issues.apache.org/jira/browse/CALCITE-4034
[jira] [Created] (CALCITE-4391) When the join condition order is different, materialized view recognition fails
xzh_dz created CALCITE-4391:
---
Summary: When the join condition order is different, materialized
view recognition fails
Key: CALCITE-4391
URL: https://issues.apache.org/jira/browse/CALCITE-4391
Project: Calcite
Issue Type: Wish
Reporter: xzh_dz
When the child nodes of join are identical, but the order of join conditions is
different, materialized view recognition will fail.
{code:java}
// code placeholder
String query = ""
+ "select a.empid, a.deptno\n"
+ "from emps a left join emps_table b\n"
+ "on a.empid = b.empid and a.deptno = b.deptno";
String mvLogic = ""
+ "select a.deptno, a.empid\n"
+ "from emps a left join emps_table b\n"
+ "on a.deptno = b.deptno and a.empid = b.empid";
Query:
LogicalProject(empid=[$0], deptno=[$1])
LogicalJoin(condition=[AND(=($0, $5), =($1, $6))], joinType=[left])
LogicalTableScan(table=[[default, emps]])
LogicalTableScan(table=[[default, emps_table]])
MV:
LogicalProject(deptno=[$1], empid=[$0])
LogicalJoin(condition=[AND(=($1, $6), =($0, $5))], joinType=[left])
LogicalTableScan(table=[[default, emps]])
LogicalTableScan(table=[[default, emps_table]]){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4390) SqlMatchRecognize returns wrong operand list
Dawid Wysakowicz created CALCITE-4390:
-
Summary: SqlMatchRecognize returns wrong operand list
Key: CALCITE-4390
URL: https://issues.apache.org/jira/browse/CALCITE-4390
Project: Calcite
Issue Type: Bug
Reporter: Dawid Wysakowicz
The {{SqlMatchRecognize}} does not return full list of its operands. The method
{{SqlMatchRecognizeOperator#createCall}} expects 12 operands whereas
{{SqlMatchRecognize#getOperandList}} returns only 10. It misses
{{rowsPerMatch}} and {{interval}}.
It results that the {{SqlShuttle}} and more concretely the
{{CallCopyingArgHandler}} does not work with {{SqlMatchRecognize}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
