[
https://issues.apache.org/jira/browse/IMPALA-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
weihua zhang updated IMPALA-14442:
----------------------------------
Description:
The original assumption of the ExtractLiteralAggrule was that there is only
one aggregate call and it is a literal aggregate, and the first n-1 columns
remain unchanged in the newly created Project.
However, in the following use case:
{code:sql}
CREATE TABLE dept(
deptno INT,
dname string,
loc string
);
CREATE TABLE emp(
empno INT,
ename string,
job string,
age INT,
mgr INT,
hiredate DATE,
sal double,
comm double,
deptno INT,
email string,
create_datetime TIMESTAMP,
upsert_time TIMESTAMP
);
select e.deptno, e.deptno < some (select deptno from emp where emp.ename =
e.ename) as v from emp as e;
{code}
The logical plan contains:
{code:java}
LogicalProject(DEPTNO=[$8], V=[OR(AND(IS TRUE(<($8, $13)), IS NOT TRUE(OR(IS
NULL($16), =($14, 0)))), AND(IS TRUE(>($14, $15)), null, IS NOT TRUE(OR(IS
NULL($16), =($14, 0))), IS NOT TRUE(<($8, $13))), AND(<($8, $13), IS NOT
TRUE(OR(IS NULL($16), =($14, 0))), IS NOT TRUE(<($8, $13)), IS NOT TRUE(>($14,
$15))))]), id = 341
LogicalJoin(condition=[IS NOT DISTINCT FROM($1, $12)], joinType=[left]), id =
339
LogicalTableScan(table=[[scott, emp]]), id = 249
LogicalProject(ename=[$0], m=[$2], c=[CASE(IS NOT NULL($3), $3, 0)],
d=[CASE(IS NOT NULL($4), $4, 0)], trueLiteral=[$5]), id = 337
LogicalJoin(condition=[IS NOT DISTINCT FROM($0, $1)], joinType=[left]),
id = 335
LogicalAggregate(group=[{1}]), id = 327
LogicalTableScan(table=[[scott, emp]]), id = 249
LogicalAggregate(group=[{0}], m=[MAX($1)], c=[COUNT()], d=[COUNT($1)],
trueLiteral=[LITERAL_AGG(true)]), id = 333
LogicalProject(ename=[$1], DEPTNO=[$8]), id = 331
LogicalFilter(condition=[IS NOT NULL($1)]), id = 329
LogicalTableScan(table=[[scott, emp]]), id = 249
{code}
The current implementation of ExtractLiteralAgg can not handle the LITERAL_AGG
transformation.
was:
The original assumption of the ExtractLiteralAggrule was that there is only
one aggregate call and it is a literal aggregate, and the first n-1 columns
remain unchanged in the newly created Project.
However, in the following use case:
{code:sql}
CREATE TABLE dept(
deptno INT,
dname string,
loc string
);
CREATE TABLE emp(
empno INT,
ename string,
job string,
age INT,
mgr INT,
hiredate DATE,
sal double,
comm double,
deptno INT,
email string,
create_datetime TIMESTAMP,
upsert_time TIMESTAMP
);
select e.deptno, e.deptno < some (select deptno from emp where emp.ename =
e.ename) as v from emp as e;
{code}
The logical plan contains:
{code:java}
LogicalProject(DEPTNO=[$8], V=[OR(AND(IS TRUE(<($8, $13)), IS NOT TRUE(OR(IS
NULL($16), =($14, 0)))), AND(IS TRUE(>($14, $15)), null, IS NOT TRUE(OR(IS
NULL($16), =($14, 0))), IS NOT TRUE(<($8, $13))), AND(<($8, $13), IS NOT
TRUE(OR(IS NULL($16), =($14, 0))), IS NOT TRUE(<($8, $13)), IS NOT TRUE(>($14,
$15))))]), id = 341
LogicalJoin(condition=[IS NOT DISTINCT FROM($1, $12)], joinType=[left]), id =
339
LogicalTableScan(table=[[scott, emp]]), id = 249
LogicalProject(ename=[$0], m=[$2], c=[CASE(IS NOT NULL($3), $3, 0)],
d=[CASE(IS NOT NULL($4), $4, 0)], trueLiteral=[$5]), id = 337
LogicalJoin(condition=[IS NOT DISTINCT FROM($0, $1)], joinType=[left]),
id = 335
LogicalAggregate(group=[{1}]), id = 327
LogicalTableScan(table=[[scott, emp]]), id = 249
LogicalAggregate(group=[{0}], m=[MAX($1)], c=[COUNT()], d=[COUNT($1)],
trueLiteral=[LITERAL_AGG(true)]), id = 333
LogicalProject(ename=[$1], DEPTNO=[$8]), id = 331
LogicalFilter(condition=[IS NOT NULL($1)]), id = 329
LogicalTableScan(table=[[scott, emp]]), id = 249
{code}
The current implementation of ExtractLiteralAggcannot handle the
LITERAL_AGGtransformation.
> Calcite Planner: Expand the processing scope of the ExtractLiteralAgg rule
> --------------------------------------------------------------------------
>
> Key: IMPALA-14442
> URL: https://issues.apache.org/jira/browse/IMPALA-14442
> Project: IMPALA
> Issue Type: Sub-task
> Reporter: weihua zhang
> Priority: Major
>
> The original assumption of the ExtractLiteralAggrule was that there is only
> one aggregate call and it is a literal aggregate, and the first n-1 columns
> remain unchanged in the newly created Project.
> However, in the following use case:
> {code:sql}
> CREATE TABLE dept(
> deptno INT,
> dname string,
> loc string
> );
> CREATE TABLE emp(
> empno INT,
> ename string,
> job string,
> age INT,
> mgr INT,
> hiredate DATE,
> sal double,
> comm double,
> deptno INT,
> email string,
> create_datetime TIMESTAMP,
> upsert_time TIMESTAMP
> );
> select e.deptno, e.deptno < some (select deptno from emp where emp.ename =
> e.ename) as v from emp as e;
> {code}
> The logical plan contains:
> {code:java}
> LogicalProject(DEPTNO=[$8], V=[OR(AND(IS TRUE(<($8, $13)), IS NOT TRUE(OR(IS
> NULL($16), =($14, 0)))), AND(IS TRUE(>($14, $15)), null, IS NOT TRUE(OR(IS
> NULL($16), =($14, 0))), IS NOT TRUE(<($8, $13))), AND(<($8, $13), IS NOT
> TRUE(OR(IS NULL($16), =($14, 0))), IS NOT TRUE(<($8, $13)), IS NOT
> TRUE(>($14, $15))))]), id = 341
> LogicalJoin(condition=[IS NOT DISTINCT FROM($1, $12)], joinType=[left]), id
> = 339
> LogicalTableScan(table=[[scott, emp]]), id = 249
> LogicalProject(ename=[$0], m=[$2], c=[CASE(IS NOT NULL($3), $3, 0)],
> d=[CASE(IS NOT NULL($4), $4, 0)], trueLiteral=[$5]), id = 337
> LogicalJoin(condition=[IS NOT DISTINCT FROM($0, $1)], joinType=[left]),
> id = 335
> LogicalAggregate(group=[{1}]), id = 327
> LogicalTableScan(table=[[scott, emp]]), id = 249
> LogicalAggregate(group=[{0}], m=[MAX($1)], c=[COUNT()],
> d=[COUNT($1)], trueLiteral=[LITERAL_AGG(true)]), id = 333
> LogicalProject(ename=[$1], DEPTNO=[$8]), id = 331
> LogicalFilter(condition=[IS NOT NULL($1)]), id = 329
> LogicalTableScan(table=[[scott, emp]]), id = 249
> {code}
> The current implementation of ExtractLiteralAgg can not handle the
> LITERAL_AGG transformation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
