Jinfeng Ni created DRILL-3316:
---------------------------------
Summary: Different SQLHandlers should go through the same planning
logics.
Key: DRILL-3316
URL: https://issues.apache.org/jira/browse/DRILL-3316
Project: Apache Drill
Issue Type: Bug
Components: Query Planning & Optimization
Reporter: Jinfeng Ni
Assignee: Jinfeng Ni
Given a SQL SELECT statement s, if we 1) run the SELECT statement alone, 2) put
it under a CTAS statement, 3) put it under a CREATE VIEW statement, 4) put it
under a EXPLAIN PLAN statement, this statement should go through the same
planning logics, and expect the same behavior.
However, this is not the case today. For instance, some SQL functionalities or
data types are not supported and will hit UNSUPPORTED OPERATOR error, if we run
the SELECT statement alone. But if we put it under CREATE VIEW statement, it
will pass and the error is delayed until we query the view.
Another example, if the query has window function, the planner will call a
HepPlanner to do some additional planning work just for the window function.
However, if the same SELECT statement is put under a CTAS statement, the
additional planning work is skipped. This most likely will hit execution error,
or return completely wrong result. This leads to issues reported in DRILL-3293
/ DRILL-3294.
Lastly, the same SELECT statement might get different plan if run alone, or run
under CTAS, since different planning setting might be set.
In this JIRA, we are going to refactor part of SqlHandler code in query
planning component, such that the same SELECT statement will go through the
same planning logic, whether it use DefaultSqlHandler, or CreateTableHandler,
or CreateViewHandler, or ExplainHandler.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
