You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Alex Chistyakov (JIRA)" <ji...@apache.org> on 2017/11/08 18:10:00 UTC
[jira] [Updated] (PHOENIX-4359) Explain plan returns incorrect
number of EST_BYTES_READ and EST_ROWS_READ for a salted table
[ 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)