[
https://issues.apache.org/jira/browse/PHOENIX-4995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-4995:
-----------------------------------
Description:
In this case this was a SEMI with this plan:
{code:java}
+-------------------------------------------------------------------------------+-----------------+----------------+--------------+
| PLAN | EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
+-------------------------------------------------------------------------------+-----------------+----------------+--------------+
| CLIENT 9-CHUNK 952560 ROWS 81920160 BYTES PARALLEL 9-WAY FULL SCAN OVER TEST
| 390 | 10 | 0 |
| SERVER TOP 10 ROWS SORTED BY [TEST.V2] | 390 | 10 | 0 |
| CLIENT MERGE SORT | 390 | 10 | 0 |
| CLIENT LIMIT 10 | 390 | 10 | 0 |
| SKIP-SCAN-JOIN TABLE 0 | 390 | 10 | 0 |
| CLIENT 1-CHUNK 10 ROWS 390 BYTES SERIAL 1-WAY FULL SCAN OVER G1 | 390 | 10 |
0 |
| SERVER FILTER BY FIRST KEY ONLY | 390 | 10 | 0 |
| SERVER 10 ROW LIMIT | 390 | 10 | 0 |
| CLIENT 10 ROW LIMIT | 390 | 10 | 0 |
| DYNAMIC SERVER FILTER BY "TEST.PK" IN ($11.$13) | 390 | 10 | 0 |
+-------------------------------------------------------------------------------+-----------------+----------------+--------------+
{code}
You can see that it estimates the LHS with 900k rows and 81MB of bytes, but
then the EST_BYTES_READ comes to just 390 bytes (which is actually correct for
this plan)
was:
In this case this was a SEMI join of the form:
> Discreptany of internal cost estimation is EXPLAIN cost for HashJoins
> ---------------------------------------------------------------------
>
> Key: PHOENIX-4995
> URL: https://issues.apache.org/jira/browse/PHOENIX-4995
> Project: Phoenix
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Priority: Minor
>
> In this case this was a SEMI with this plan:
> {code:java}
> +-------------------------------------------------------------------------------+-----------------+----------------+--------------+
> | PLAN | EST_BYTES_READ | EST_ROWS_READ | EST_INFO_TS |
> +-------------------------------------------------------------------------------+-----------------+----------------+--------------+
> | CLIENT 9-CHUNK 952560 ROWS 81920160 BYTES PARALLEL 9-WAY FULL SCAN OVER
> TEST | 390 | 10 | 0 |
> | SERVER TOP 10 ROWS SORTED BY [TEST.V2] | 390 | 10 | 0 |
> | CLIENT MERGE SORT | 390 | 10 | 0 |
> | CLIENT LIMIT 10 | 390 | 10 | 0 |
> | SKIP-SCAN-JOIN TABLE 0 | 390 | 10 | 0 |
> | CLIENT 1-CHUNK 10 ROWS 390 BYTES SERIAL 1-WAY FULL SCAN OVER G1 | 390 | 10
> | 0 |
> | SERVER FILTER BY FIRST KEY ONLY | 390 | 10 | 0 |
> | SERVER 10 ROW LIMIT | 390 | 10 | 0 |
> | CLIENT 10 ROW LIMIT | 390 | 10 | 0 |
> | DYNAMIC SERVER FILTER BY "TEST.PK" IN ($11.$13) | 390 | 10 | 0 |
> +-------------------------------------------------------------------------------+-----------------+----------------+--------------+
> {code}
> You can see that it estimates the LHS with 900k rows and 81MB of bytes, but
> then the EST_BYTES_READ comes to just 390 bytes (which is actually correct
> for this plan)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
