[ 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)