[
https://issues.apache.org/jira/browse/PHOENIX-4359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Chistyakov updated PHOENIX-4359:
-------------------------------------
Description:
Table INVOICES_V6 is a salted version of INVOICES_V5 with exactly the same data.
Two exact queries have very different plans on them:
{{0: jdbc:phoenix:192.168.160.123,192.168.160.1> EXPLAIN SELECT COUNT(*) FROM
INVOICES_V5 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN = '6685003522' ) );}}
{{+----------------------------------------------------------------------------------------------------+-----------------+----------------+}}
{{| PLAN
| EST_BYTES_READ | EST_ROWS_READ |}}
{{+----------------------------------------------------------------------------------------------------+-----------------+----------------+}}
{{| CLIENT 1-CHUNK 0 ROWS 0 BYTES PARALLEL 1-WAY RANGE SCAN OVER INVOICES_V5
['y2016q2','6685003522'] | 0 | 0 |}}
{{| SERVER FILTER BY FIRST KEY ONLY
| 0 | 0 |}}
{{| SERVER AGGREGATE INTO SINGLE ROW
| 0 | 0 |}}
+----------------------------------------------------------------------------------------------------+-----------------+----------------+
3 rows selected (0.046 seconds)
0: jdbc:phoenix:192.168.160.123,192.168.160.1> SELECT /*+ SKIP_SCAN, NO_CACHE
*/ COUNT(*) FROM INVOICES_V6 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN =
'6685003522' ) );
+-----------+
| COUNT(1) |
+-----------+
| 108 |
+-----------+
1 row selected (0.185 seconds)
0: jdbc:phoenix:192.168.160.123,192.168.160.1> EXPLAIN SELECT COUNT(*) FROM
INVOICES_V6 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN = '6685003522' ) );
+----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
|
PLAN
| EST_BYTES_READ | EST_ROWS_READ |
+----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
| CLIENT 256-CHUNK 58635313 ROWS 67874370912 BYTES PARALLEL 256-WAY RANGE SCAN
OVER INVOICES_V6 [0,'y2016q2','6685003522'] - [255,'y2016q2','6685003522'] |
67874370912 | 58635313 |
| SERVER FILTER BY FIRST KEY ONLY
|
67874370912 | 58635313 |
| SERVER AGGREGATE INTO SINGLE ROW
|
67874370912 | 58635313 |
+----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
3 rows selected (0.048 seconds)
0: jdbc:phoenix:192.168.160.123,192.168.160.1>}}
The plan on V6 doesn't seem to be real, Phoenix definitely does not read 60+ Gb.
was:
Table INVOICES_V6 is a salted version of INVOICES_V5 with exactly the same data.
Two exact queries have very different plans on them:
{{0: jdbc:phoenix:192.168.160.123,192.168.160.1> EXPLAIN SELECT COUNT(*) FROM
INVOICES_V5 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN = '6685003522' ) );
+----------------------------------------------------------------------------------------------------+-----------------+----------------+
| PLAN
| EST_BYTES_READ | EST_ROWS_READ |
+----------------------------------------------------------------------------------------------------+-----------------+----------------+
| CLIENT 1-CHUNK 0 ROWS 0 BYTES PARALLEL 1-WAY RANGE SCAN OVER INVOICES_V5
['y2016q2','6685003522'] | 0 | 0 |
| SERVER FILTER BY FIRST KEY ONLY
| 0 | 0 |
| SERVER AGGREGATE INTO SINGLE ROW
| 0 | 0 |
+----------------------------------------------------------------------------------------------------+-----------------+----------------+
3 rows selected (0.046 seconds)
0: jdbc:phoenix:192.168.160.123,192.168.160.1> SELECT /*+ SKIP_SCAN, NO_CACHE
*/ COUNT(*) FROM INVOICES_V6 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN =
'6685003522' ) );
+-----------+
| COUNT(1) |
+-----------+
| 108 |
+-----------+
1 row selected (0.185 seconds)
0: jdbc:phoenix:192.168.160.123,192.168.160.1> EXPLAIN SELECT COUNT(*) FROM
INVOICES_V6 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN = '6685003522' ) );
+----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
|
PLAN
| EST_BYTES_READ | EST_ROWS_READ |
+----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
| CLIENT 256-CHUNK 58635313 ROWS 67874370912 BYTES PARALLEL 256-WAY RANGE SCAN
OVER INVOICES_V6 [0,'y2016q2','6685003522'] - [255,'y2016q2','6685003522'] |
67874370912 | 58635313 |
| SERVER FILTER BY FIRST KEY ONLY
|
67874370912 | 58635313 |
| SERVER AGGREGATE INTO SINGLE ROW
|
67874370912 | 58635313 |
+----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
3 rows selected (0.048 seconds)
0: jdbc:phoenix:192.168.160.123,192.168.160.1>}}
The plan on V6 doesn't seem to be real, Phoenix definitely does not read 60+ Gb.
> Explain plan returns incorrect number of EST_BYTES_READ and EST_ROWS_READ for
> a salted table
> --------------------------------------------------------------------------------------------
>
> Key: PHOENIX-4359
> URL: https://issues.apache.org/jira/browse/PHOENIX-4359
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.11.0
> Reporter: Alex Chistyakov
>
> Table INVOICES_V6 is a salted version of INVOICES_V5 with exactly the same
> data.
> Two exact queries have very different plans on them:
> {{0: jdbc:phoenix:192.168.160.123,192.168.160.1> EXPLAIN SELECT COUNT(*) FROM
> INVOICES_V5 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN = '6685003522' ) );}}
> {{+----------------------------------------------------------------------------------------------------+-----------------+----------------+}}
> {{| PLAN
> | EST_BYTES_READ | EST_ROWS_READ |}}
> {{+----------------------------------------------------------------------------------------------------+-----------------+----------------+}}
> {{| CLIENT 1-CHUNK 0 ROWS 0 BYTES PARALLEL 1-WAY RANGE SCAN OVER INVOICES_V5
> ['y2016q2','6685003522'] | 0 | 0 |}}
> {{| SERVER FILTER BY FIRST KEY ONLY
> | 0 | 0 |}}
> {{| SERVER AGGREGATE INTO SINGLE ROW
> | 0 | 0 |}}
> +----------------------------------------------------------------------------------------------------+-----------------+----------------+
> 3 rows selected (0.046 seconds)
> 0: jdbc:phoenix:192.168.160.123,192.168.160.1> SELECT /*+ SKIP_SCAN, NO_CACHE
> */ COUNT(*) FROM INVOICES_V6 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN =
> '6685003522' ) );
> +-----------+
> | COUNT(1) |
> +-----------+
> | 108 |
> +-----------+
> 1 row selected (0.185 seconds)
> 0: jdbc:phoenix:192.168.160.123,192.168.160.1> EXPLAIN SELECT COUNT(*) FROM
> INVOICES_V6 WHERE ( ( PERIOD = 'y2016q2' AND OWNER_INN = '6685003522' ) );
> +----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> |
> PLAN
> | EST_BYTES_READ | EST_ROWS_READ |
> +----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> | CLIENT 256-CHUNK 58635313 ROWS 67874370912 BYTES PARALLEL 256-WAY RANGE
> SCAN OVER INVOICES_V6 [0,'y2016q2','6685003522'] -
> [255,'y2016q2','6685003522'] | 67874370912 | 58635313 |
> | SERVER FILTER BY FIRST KEY ONLY
>
> | 67874370912 | 58635313 |
> | SERVER AGGREGATE INTO SINGLE ROW
>
> | 67874370912 | 58635313 |
> +----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> 3 rows selected (0.048 seconds)
> 0: jdbc:phoenix:192.168.160.123,192.168.160.1>}}
> The plan on V6 doesn't seem to be real, Phoenix definitely does not read 60+
> Gb.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
