phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriel Reid (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3471) Allow accessing full (legacy) Phoenix EXPLAIN information via Calcite
Date Thu, 10 Nov 2016 18:12:58 GMT

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

Mime
View raw message