[
https://issues.apache.org/jira/browse/PHOENIX-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17062982#comment-17062982
]
Sokolov Yura commented on PHOENIX-4642:
---------------------------------------
Two years passed, and there is no answer to bug that looks like critical...
Great...
This is one of reasons there is no Phoenix in our company any more.
> Select from local index in backward direction returns only from last region.
> ----------------------------------------------------------------------------
>
> Key: PHOENIX-4642
> URL: https://issues.apache.org/jira/browse/PHOENIX-4642
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.11.0
> Environment: Amazon EMR HBase 1.3 Phoenix 4.11 .
> Reporter: Sokolov Yura
> Priority: Major
>
> I have a table:
> {code}
> CREATE TABLE IF NOT EXISTS PRODUCT_HISTORY_2 (
>
>
> ts BIGINT NOT NULL,
>
> id VARCHAR NOT NULL,
>
> merchantId VARCHAR,
>
> storeId VARCHAR,
>
> a.product VARCHAR,
>
> CONSTRAINT pk PRIMARY KEY(ts, id)
>
> )
> COMPRESSION=GZ,VERSIONS=2,UPDATE_CACHE_FREQUENCY=1000,APPEND_ONLY_SCHEMA=true,IMMUTABLE_ROWS=true;
>
>
>
> CREATE LOCAL INDEX IF NOT EXISTS PRODUCT_HISTORY_2_ID_TS ON PRODUCT_HISTORY_2
> (
> id, ts
>
> ) COMPRESSION=GZ;
> {code}
> It is large enough to be splitted into 16 regions.
> Now I want to select alll items by id:
> {code}
> 0: jdbc:phoenix:localhost:2181:/hbase> select id, ts from product_history_2
> where id = '1491199695565244581-139-1-582-3894176988' order by ts;
> +-------------------------------------------+----------------+
> | ID | TS |
> +-------------------------------------------+----------------+
> | 1491199695565244581-139-1-582-3894176988 | 1498709133486 |
> | 1491199695565244581-139-1-582-3894176988 | 1498810584706 |
> | 1491199695565244581-139-1-582-3894176988 | 1499083503309 |
> | 1491199695565244581-139-1-582-3894176988 | 1499170817262 |
> | 1491199695565244581-139-1-582-3894176988 | 1503663938614 |
> | 1491199695565244581-139-1-582-3894176988 | 1506596564228 |
> | 1491199695565244581-139-1-582-3894176988 | 1509714911254 |
> | 1491199695565244581-139-1-582-3894176988 | 1517514069109 |
> +-------------------------------------------+----------------+
> 8 rows selected (0,107 seconds)
> {code}
> And now I want to fetch same rows, but with time descending:
> {code}
> 0: jdbc:phoenix:localhost:2181:/hbase> select id, ts from product_history_2
> where id = '1491199695565244581-139-1-582-3894176988' order by ts desc;
> +-------------------------------------------+----------------+
> | ID | TS |
> +-------------------------------------------+----------------+
> | 1491199695565244581-139-1-582-3894176988 | 1517514069109 |
> | 1491199695565244581-139-1-582-3894176988 | 1509714911254 |
> +-------------------------------------------+----------------+
> 2 rows selected (0,048 seconds)
> {code}
> Ooops, where are other 6 rows?
> Both queries uses local index:
> {code}
> 0: jdbc:phoenix:localhost:2181:/hbase> explain select id, ts from
> product_history_2 where id = '1491199695565244581-139-1-582-3894176988' order
> by ts;
> +--------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> | PLAN
> |
> EST_BYTES_READ | EST_ROWS_READ |
> +--------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> | CLIENT 14-CHUNK 34026740 ROWS 4089447171 BYTES PARALLEL 14-WAY RANGE SCAN
> OVER PRODUCT_HISTORY_2 [1,'1491199695565244581-139-1-582-3894176988'] | null
> | null |
> | SERVER FILTER BY FIRST KEY ONLY
> | null
> | null |
> | CLIENT MERGE SORT
> | null
> | null |
> +--------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> 3 rows selected (0,024 seconds)
> 0: jdbc:phoenix:localhost:2181:/hbase> explain select id, ts from
> product_history_2 where id = '1491199695565244581-139-1-582-3894176988' order
> by ts desc;
> +----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> |
> PLAN
> | EST_BYTES_READ | EST_ROWS_READ |
> +----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> | CLIENT 14-CHUNK 34026740 ROWS 4089447171 BYTES PARALLEL 14-WAY REVERSE
> RANGE SCAN OVER PRODUCT_HISTORY_2
> [1,'1491199695565244581-139-1-582-3894176988'] | null | null
> |
> | SERVER FILTER BY FIRST KEY ONLY
>
> | null | null |
> | CLIENT MERGE SORT
>
> | null | null |
> +----------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+----------------+
> 3 rows selected (0,018 seconds)
> {code}
> Possibly related bugs are : PHOENIX-3898 and PHOENIX-4292
> Unfortunately I can no test phoenix 4.13 yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
