[
https://issues.apache.org/jira/browse/PHOENIX-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15310627#comment-15310627
]
Lars Hofhansl commented on PHOENIX-258:
---------------------------------------
So specifically:
bq. You have to pad with some number of arbitrary 0xFF bytes (and there'd
always be the case of not adding enough, but it's the best we can do). The only
time this can happen is if the last field is VARBINARY, as 0xFF isn't a valid
byte for VARCHAR or DECIMAL.
But since VARBINARY cannot be last in a multipart key and optimization doesn't
happen unless we're using strictly less keys than the table's keys, in practice
this can never happen.
Right?
> 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)
