[
https://issues.apache.org/jira/browse/PHOENIX-4288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16213200#comment-16213200
]
James Taylor commented on PHOENIX-4288:
---------------------------------------
[~maryannxue] - this would be a good one for you if you have some spare cycles.
Currently Phoenix always chooses to optimize out an ORDER BY as opposed to
optimizing based on the filter. Since we can get at compile time the number of
bytes that will be scanned if we were to optimize based on the filter (since in
this case it'd be using an index that leads with the column being filtered on),
we could make a cost based decision instead.
WDYT?
> Indexes not used when ordering by primary key
> ---------------------------------------------
>
> Key: PHOENIX-4288
> URL: https://issues.apache.org/jira/browse/PHOENIX-4288
> Project: Phoenix
> Issue Type: Bug
> Reporter: Marcin Januszkiewicz
>
> We have a table
> CREATE TABLE t (
> rowkey VARCHAR PRIMARY KEY,
> c1 VARCHAR,
> c2 VARCHAR
> )
> which we want to query by doing partial matches on c1, and keep the ordering
> of the source table:
> SELECT rowkey, c1, c2 FROM t where c1 LIKE 'X0%' ORDER BY rowkey;
> We expect most queries to select a small subset of the table, so we create an
> index to speed up searches:
> CREATE LOCAL INDEX t_c1_ix ON t (c1);
> However, this index will not be used since Phoenix will always choose not to
> resort the data.
> In our actual use case, adding index hints is not a practical solution.
> See also discussion at:
> https://lists.apache.org/thread.html/26ab58288eb811d2f074c3f89067163d341e5531fb581f3b2486cf43@%3Cuser.phoenix.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
