[
https://issues.apache.org/jira/browse/PHOENIX-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15310651#comment-15310651
]
Lars Hofhansl commented on PHOENIX-258:
---------------------------------------
bq. The reverse scan case is tricky. Padding with a single 0xFF isn't
necessarily enough, as if the next field is a BIGINT, you'd need 8 0xFF bytes,
and if the field after that is an INTEGER, you'd need 4 more 0xFF bytes.
I don't think that is needed. I ran through this with the debugger. Let's say
we have a two part prefix. INT/INT, and let's say the values are 1/1, 2/1, and
3/1.
In the reverse case we'll 3/1. So we'll seek to 2\0xFF. It does not matter what
follows, since we're guaranteed to see at least 2 as the next first part of the
key. After that we'll seek 1\0xFF. This seems to be correct in all cases.
> Use skip scan when SELECT DISTINCT on leading row key column(s)
> ---------------------------------------------------------------
>
> Key: PHOENIX-258
> URL: https://issues.apache.org/jira/browse/PHOENIX-258
> Project: Phoenix
> Issue Type: Task
> Reporter: ryang-sfdc
> Assignee: Lars Hofhansl
> Fix For: 4.8.0
>
> Attachments: 258-WIP.txt, 258-v1.txt, 258-v10.txt, 258-v11.txt,
> 258-v12.txt, 258-v13.txt, 258-v14.txt, 258-v2.txt, 258-v3.txt, 258-v4.txt,
> 258-v5.txt, 258-v6.txt, 258-v7.txt, 258-v8.txt, 258-v9.txt, 258.txt,
> DistinctFixedPrefixFilter.java, in-clause.png
>
>
> create table(a varchar(32) not null, date date not null constraint pk primary
> key(a,date))
> [["PLAN"],["CLIENT PARALLEL 94-WAY FULL SCAN OVER foo"],[" SERVER
> AGGREGATE INTO ORDERED DISTINCT ROWS BY [a]"],["CLIENT MERGE SORT"]]
>
> We should skip scan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
