Re: [QUESTION] Pushing up evaluations from LogicalProjects
Filed a JIRA: https://issues.apache.org/jira/browse/CALCITE-3405 Haisheng Yuan 于2019年10月12日周六 上午4:34写道： > Yes, definitely. > > You can go through the project expression with InputFinder to find all the > used columns, create a logical project with those columns, and remap the > top project with new column indexes. > > On the other hand, instead of creating a new intermidiate pogical project, > we can also update ProjectTableScanRule to accept LogicalProject that is > not a simple mapping, and do the same task I mentioned above. > > - Haisheng > > -- > 发件人：Rommel Quintanilla > 日 期：2019年10月12日 03:15:31 > 收件人： > 主 题：[QUESTION] Pushing up evaluations from LogicalProjects > > Hi, maybe you can help me. > I have this portion from a larger logical plan: > .. > LogicalProject(l_orderkey=[$0], l_suppkey=[$2], *=[*($5, -(1, > $6))]) > LogicalTableScan(table=[[main, lineitem]]) > .. > > Because the LogicalProject above contains an evaluation, the > ProjectTableScanRule can't convert it to a BindableTableScan. > > I wonder if somehow the evaluation could be pushed up more or less like > this: > .. > LogicalProject(l_orderkey=[$0], l_suppkey=[$1], *=[*($2, -(1, $3))]) > LogicalProject(l_orderkey=[$0], l_suppkey=[$2], l_extendedprice=[$5], > l_discount=[$6]]) > LogicalTableScan(table=[[main, lineitem]]) > .. > > Regards. >
[jira] [Created] (CALCITE-3405) Pruning columns for ProjectableFilterable when project is not simple mapping
jin xing created CALCITE-3405: - Summary: Pruning columns for ProjectableFilterable when project is not simple mapping Key: CALCITE-3405 URL: https://issues.apache.org/jira/browse/CALCITE-3405 Project: Calcite Issue Type: Bug Reporter: jin xing Assignee: jin xing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3404) Promote plan for AggregateExpandDistinctAggregatesRule when all the agg expressions are distinct and have same arguments
Danny Chen created CALCITE-3404:
---
Summary: Promote plan for AggregateExpandDistinctAggregatesRule
when all the agg expressions are distinct and have same arguments
Key: CALCITE-3404
URL: https://issues.apache.org/jira/browse/CALCITE-3404
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.21.0
Reporter: Danny Chen
Assignee: Danny Chen
Fix For: 1.22.0
After CALCITE-3159, the distinct constraint for MAX/MIN/BIT_OR/BIT_AND are
removed automatically, so if we have a query:
{code:sql}
select sum(distinct deptno), count(distinct deptno), max(deptno) from emp
{code}
Than plan has regression from
{code:xml}
LogicalAggregate(group=[{}], EXPR$0=[SUM($0)], EXPR$1=[COUNT($0)],
EXPR$2=[MAX($0)])
LogicalAggregate(group=[{0}])
LogicalProject(DEPTNO=[$7])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
to
{code:xml}
LogicalAggregate(group=[{}], EXPR$0=[SUM($0) FILTER $2], EXPR$1=[COUNT($0)
FILTER $2], EXPR$2=[MIN($1) FILTER $3])
LogicalProject(DEPTNO=[$0], EXPR$2=[$1], $g_0=[=($2, 0)], $g_1=[=($2, 1)])
LogicalAggregate(group=[{0}], groups=[[{0}, {}]], EXPR$2=[MAX($0)],
$g=[GROUPING($0)])
LogicalProject(DEPTNO=[$7])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
{code}
The distinct trait actually can be reused.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Apache Calcite Geode
Hi All, I am looking good examples or document /tutorials/sample code for Apache Calcite Geode,unfortunately noting is available on net , only one talk from tzolv. I have raised following question few month back and now able to connect now . https://stackoverflow.com/questions/49411169/apache-calcite-geode-jdbc-adapte-not-working-with-gemfire-8-x-and-9-x/58343449#58343449 I am try to use Apache spark Job to load data on gemfire using Apache Calcite Geode adopter . I am also interested to create good reference for other users they are facing same problems . Any help greatly appreciated. Regards, Viquar khan
[jira] [Created] (CALCITE-3403) WindowReduceExpressionsRule does not reuse RelMetadataQuery
Haisheng Yuan created CALCITE-3403: -- Summary: WindowReduceExpressionsRule does not reuse RelMetadataQuery Key: CALCITE-3403 URL: https://issues.apache.org/jira/browse/CALCITE-3403 Project: Calcite Issue Type: Improvement Reporter: Haisheng Yuan It creates a new RelMetadataQuery instance, which is a fresh RelMetadataQuery without any data cache. We should get RelMetadataQuery from RelOptRuleCall to reuse cache as much as possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [QUESTION] Pushing up evaluations from LogicalProjects
Yes, definitely. You can go through the project expression with InputFinder to find all the used columns, create a logical project with those columns, and remap the top project with new column indexes. On the other hand, instead of creating a new intermidiate pogical project, we can also update ProjectTableScanRule to accept LogicalProject that is not a simple mapping, and do the same task I mentioned above. - Haisheng -- 发件人：Rommel Quintanilla 日 期：2019年10月12日 03:15:31 收件人： 主 题：[QUESTION] Pushing up evaluations from LogicalProjects Hi, maybe you can help me. I have this portion from a larger logical plan: .. LogicalProject(l_orderkey=[$0], l_suppkey=[$2], *=[*($5, -(1, $6))]) LogicalTableScan(table=[[main, lineitem]]) .. Because the LogicalProject above contains an evaluation, the ProjectTableScanRule can't convert it to a BindableTableScan. I wonder if somehow the evaluation could be pushed up more or less like this: .. LogicalProject(l_orderkey=[$0], l_suppkey=[$1], *=[*($2, -(1, $3))]) LogicalProject(l_orderkey=[$0], l_suppkey=[$2], l_extendedprice=[$5], l_discount=[$6]]) LogicalTableScan(table=[[main, lineitem]]) .. Regards.
[QUESTION] Pushing up evaluations from LogicalProjects
Hi, maybe you can help me. I have this portion from a larger logical plan: .. LogicalProject(l_orderkey=[$0], l_suppkey=[$2], *=[*($5, -(1, $6))]) LogicalTableScan(table=[[main, lineitem]]) .. Because the LogicalProject above contains an evaluation, the ProjectTableScanRule can't convert it to a BindableTableScan. I wonder if somehow the evaluation could be pushed up more or less like this: .. LogicalProject(l_orderkey=[$0], l_suppkey=[$1], *=[*($2, -(1, $3))]) LogicalProject(l_orderkey=[$0], l_suppkey=[$2], l_extendedprice=[$5], l_discount=[$6]]) LogicalTableScan(table=[[main, lineitem]]) .. Regards.
[jira] [Created] (CALCITE-3402) Allow RANGE with compoud ORDER BY clause
benj created CALCITE-3402:
-
Summary: Allow RANGE with compoud ORDER BY clause
Key: CALCITE-3402
URL: https://issues.apache.org/jira/browse/CALCITE-3402
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.19.0, 1.18.0
Reporter: benj
It will be very useful to have the capacity to use compound ORDER BY clause
with RANGE
{code:sql}
apache drill (dfs.tmp)> SELECT a
, last_value(c) OVER(PARTITION BY a ORDER BY c, b DESC RANGE BETWEEN UNBOUNDED
PRECEDING AND UNBOUNDED FOLLOWING)
FROM (SELECT 1 a, 'b' b, 3 c
UNION SELECT 2, 'c', 4
UNION SELECT 1, 'c', 4
/* UNION ... */
) x;
Error: VALIDATION ERROR: From line 2, column 56 to line 2, column 60: RANGE
clause cannot be used with compound ORDER BY clause
{code}
This is possible with some SGBDR like Postgres:
[https://www.postgresql.org/docs/9.3/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3401) Assume empty keystore passwords by default
István Tóth created CALCITE-3401: Summary: Assume empty keystore passwords by default Key: CALCITE-3401 URL: https://issues.apache.org/jira/browse/CALCITE-3401 Project: Calcite Issue Type: Improvement Components: avatica Reporter: István Tóth Assignee: István Tóth For the current implementation keystore, truststore, and private key passwords must always be explicitly set, otherwise avatica ignores the specified key/truststores. I propose changing the default password values to the empty string, so that unprotected key/truststores can be used without explicitly providing an empty password. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3400) Add support for interpretering outer/semi/anti/full join
Wang Yanlin created CALCITE-3400: Summary: Add support for interpretering outer/semi/anti/full join Key: CALCITE-3400 URL: https://issues.apache.org/jira/browse/CALCITE-3400 Project: Calcite Issue Type: Improvement Reporter: Wang Yanlin Currently, [JoinNode|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/interpreter/JoinNode.java#L49] can just run inner type join. We can add support for more join types for JoinNode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
