Gabriel Reid created PHOENIX-3471:
-------------------------------------
Summary: Allow accessing full (legacy) Phoenix EXPLAIN information
via Calcite
Key: PHOENIX-3471
URL: https://issues.apache.org/jira/browse/PHOENIX-3471
Project: Phoenix
Issue Type: Sub-task
Reporter: Gabriel Reid
The EXPLAIN syntax in Calcite-Phoenix (either "EXPLAIN <sql>" or "EXPLAIN PLAN
FOR <sql>") currently returns the Calcite plan for a query. For example:
{code}
EXPLAIN SELECT MAX(I) FROM T1
{code}
results in the following Calcite explain plan:
{code}
PhoenixToEnumerableConverter
PhoenixServerAggregate(group=[{}], EXPR$0=[MAX($0)])
PhoenixTableScan(table=[[phoenix, T1]])
{code}
and the following (legacy) Phoenix explain plan:
{code}
CLIENT PARALLEL 1-WAY FULL SCAN OVER T1
SERVER FILTER BY FIRST KEY ONLY
{code}
There are currently a large number of integration tests which depend on the
legacy Phoenix format of explain plan, and this format is no longer available
when running via Calcite. PHOENIX-3105 added support for accessing the explain
plan via the "EXPLAIN <sql>" syntax, but this update to the syntax still only
provides the Calcite-specific explain plan.
There are three main approaches which can be taken here:
h4. Option 1: Custom EXPLAIN execution
This approach extends the work done in PHOENIX-3105 to plug in a custom
SqlPhoenixExplain
node which returns the legacy Phoenix explain plan, with the "EXPLAIN PLAN FOR
<sql>"
syntax still returning the Calcite explain plan.
h4. Option 2: Add the legacy Phoenix explain plan to the Calcite plan as a
top-level attribute
This approach results in an explain plan that looks as follows:
{code}
PhoenixToEnumerableConverter(PhoenixExecutionPlan=[CLIENT PARALLEL 1-WAY FULL
SCAN OVER T1
SERVER FILTER BY FIRST KEY ONLY])
PhoenixServerAggregate(group=[{}], EXPR$0=[MAX($0)])
PhoenixTableScan(table=[[phoenix, T1]])
{code}
The disadvantage of this approach is that it's not really "correct" -- we're
just tacking
a different representation of the explain plan into the Calcite explain plan.
The advantage of this approach is that it's very quick and easy to implement
(i.e. it
can be done immediately), and it will require minimal changes to the many test
cases which have
hard-coded explain plans that things are checked against. All we need to do is
have a
utility to extract the PhoenixExecutionPlan value from the full Calcite plan,
and other
than that all test cases stay the same.
h4. Option 3: Add all relevant information to the correct parts of the Calcite
explain plan
This approach would result in an explain plan that looks as follows:
{code}
PhoenixToEnumerableConverter
PhoenixServerAggregate(group=[{}], EXPR$0=[MAX($0)])
PhoenixTableScan(table=[[phoenix, T1]], scanType[CLIENT PARALLEL 1-WAY FULL
])
{code}
This is undoubtedly the "right" way to do things. However, it has the major
disadvantage
that it will require a large amount of work to do the following:
* add all relevant information into various implementations of
{{AbstractRelNode.explainTerms}}
* rework all test cases which verify things against an expected explain plan
It is of course also an option is to start with option 2 here, and eventually
migrate to option 3.
If we go for option 2 or option 3, we should probably remove the custom EXPLAIN
parsing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
