[PHOENIX-2067] Sort order incorrect for variable length DESC columns

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 4.4.0
• Fix Version/s: 4.5.0

Environment

HBase 0.98.6-cdh5.3.0
jdk1.7.0_67 x64
CentOS release 6.4 (2.6.32-358.el6.x86_64)

• Assignee: James R. Taylor
• Reporter: Mykola Komarnytskyy
• Created: 24/Jun/15 15:25
• Updated: 28/Mar/23 08:30
• Resolved: 14/Jul/15 18:21

Description

Steps to reproduce:
1. Create a table:
CREATE TABLE mytable (id BIGINT not null PRIMARY KEY, timestamp BIGINT, log_message varchar) IMMUTABLE_ROWS=true, SALT_BUCKETS=16;
2. Create two indexes:
CREATE INDEX mytable_index_search ON mytable(timestamp,id) INCLUDE (log_message) SALT_BUCKETS=16;
CREATE INDEX mytable_index_search_desc ON mytable(timestamp DESC,id DESC) INCLUDE (log_message) SALT_BUCKETS=16;
3. Upsert values:
UPSERT INTO mytable VALUES(1, 1434983826018, 'message1');
UPSERT INTO mytable VALUES(2, 1434983826100, 'message2');
UPSERT INTO mytable VALUES(3, 1434983826101, 'message3');
UPSERT INTO mytable VALUES(4, 1434983826202, 'message4');
4. Sort DESC by timestamp:
select timestamp,id,log_message from mytable ORDER BY timestamp DESC;

Failure: data is sorted incorrectly. In case when we have two longs which are different only by last two digits (e.g. 1434983826155, 1434983826100) and one of the long ends with '00' we receive incorrect order.
Sorting result:
1434983826202
1434983826100
1434983826101
1434983826018

Issue Links

• is related to: PHOENIX-5318 Slots passed to SkipScan filter is incorrect for desc primary keys that are prefixes of each other
• relates to: PHOENIX-6916 Cannot handle ranges where start is a prefix of end for desc columns