Joe McDonnell created IMPALA-13568:
--------------------------------------
Summary: Calcite planner is falling back incorrectly for some
select statements
Key: IMPALA-13568
URL: https://issues.apache.org/jira/browse/IMPALA-13568
Project: IMPALA
Issue Type: Sub-task
Components: Frontend
Affects Versions: Impala 4.5.0
Reporter: Joe McDonnell
The Calcite planner tries to parse with the Calcite parser. If that fails, it
checks whether this is a select statement by parsing with the regular parser
and seeing if it is a SelectStmt. If it isn't, it falls back to the original
planner. This is great for DDL/DML and other random statements not supported by
Calcite, but this check is not quite right. This statement is a select, but it
falls back to the original planner:
{noformat}
with t1 as (select int_col x, bigint_col y from alltypestiny),
t2 as (select 1 x , 10 y), t3 as (values(2 x , 20 y), (3, 30))
select * from t1 union all select * from t2 union all (select * from t3) order
by x limit 20{noformat}
The check should be comparing against QueryStmt, which is the base class for
SelectStmt as well as SetOperationsStmt and UnionStmt.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
