[
https://issues.apache.org/jira/browse/PHOENIX-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maryann Xue resolved PHOENIX-84.
--------------------------------
Resolution: Not A Problem
The plan is shown with indent, which indicates the dependency between sub-query
executions.
For example,
if we do "select * from A join B on A.c1 = B.c1", the plan will be like:
CLIENT PARALLEL 1-WAY FULL SCAN OVER A
PARALLEL EQUI-JOIN 1 HASH TABLES:
BUILD HASH TABLE 0
CLIENT PARALLEL 1-WAY FULL SCAN OVER B
This means A is the outer table in the join execution, and depends on the hash
result of inner table B.
> explain the query plan is not the actually order
> -------------------------------------------------
>
> Key: PHOENIX-84
> URL: https://issues.apache.org/jira/browse/PHOENIX-84
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: jay wong
> Assignee: Maryann Xue
> Fix For: 3.0.0
>
>
> explain select test_join1.varchar_pk,sum(test_join2.int_column),
> min(test_join2.int_column_b) from test_join1 left join test_join2 on
> test_join1.int_column = test_join2.int_column where test_join1.int_column > 0
> GROUP BY TEST_JOIN1.VARCHAR_PK;
> | PLAN |
> | CLIENT PARALLEL 32-WAY FULL SCAN OVER TEST_JOIN1 |
> | SERVER FILTER BY INT_COLUMN > 0 |
> | SERVER AGGREGATE INTO ORDERED DISTINCT ROWS BY [TEST_JOIN1.VARCHAR_PK] |
> | CLIENT MERGE SORT |
> | PARALLEL EQUI-JOIN 1 HASH TABLES: |
> | BUILD HASH TABLE 0 |
> | CLIENT PARALLEL 32-WAY FULL SCAN OVER TEST_JOIN2 |
> but in my observe
> first step : full scan test_join2 with filter and send the result.
> sencod step: full scan test_join1 with equi-join.
> and didn't find client merge sort.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
