[
https://issues.apache.org/jira/browse/PHOENIX-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654728#comment-15654728
]
Gabriel Reid commented on PHOENIX-3471:
---------------------------------------
After discussing this with [~jamestaylor] and [~maryannxue], the plan is to go
with option 3 (i.e. do things properly right now).
> 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)
