[
https://issues.apache.org/jira/browse/PHOENIX-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277846#comment-14277846
]
Maryann Xue commented on PHOENIX-1560:
--------------------------------------
[~jamestaylor], I still don't get it. Suppose we have a query like "select *
from T order by v1", data table PKs are "k1, k2", index is on column "v1", the
query we'll get after rewriting will be:
"select * from T where (k1, k2) in (select k1, k2 from I)" (Suppose we can
finally optimize out the order by).
The IN clause values have to be ordered by datatable PK and put into
SkipScanFilter, right? That way we are not doing get() for each PK value we got
from index table scan, instead we are just doing seek in the data table regions
according to the "hints" provided by SkipScanFilter. That's how SkipScanFilter
works, correct? I don't think we currently have a mechanism to issue get()
according to the values specified in an IN clause. If the IN clause cannot be
optimized by WhereOptimizer, it will be translated as a regular filter.
> Join between global index and data table if INDEX hint used
> -----------------------------------------------------------
>
> Key: PHOENIX-1560
> URL: https://issues.apache.org/jira/browse/PHOENIX-1560
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Maryann Xue
> Attachments: 1560.patch
>
>
> We already have an INDEX hint, and we already have a mechanism to collect
> referenced columns in the data table that are not in the index table (used
> only for local indexes currently). Instead of not using the global index when
> a referenced data column is not found in the index, we should rewrite the
> query to join back to the data table when the INDEX hint is present. This is
> always possible, as we always have the data PK columns in the index table,
> and our join optimization would kick in as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
