[ 
https://issues.apache.org/jira/browse/PHOENIX-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16739127#comment-16739127
 ] 

Lars Hofhansl commented on PHOENIX-3941:
----------------------------------------

Perhaps I am missing something here.

>From the examples in the test it seems that this assumes that pk columns of 
>the table are included in the index.
I.e. if the table's pk is (A, B, C), and also has a column D, that this prune 
regions only if the index itself contains a prefix of the pk, i.e. the index 
would need to defined as ON table(A,D).

This is not necessary, right? We can *always* prune regions based on the prefix 
of the PK, no?

I.e. in the above example if the index was define ON table(D) only, and we now 
have a query
WHERE D = x, and A = b; we can still use A = b to prune the regions? Why does 
the A need to included in the index?! That seems like a bug.


> Filter regions to scan for local indexes based on data table leading pk 
> filter conditions
> -----------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-3941
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3941
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: James Taylor
>            Assignee: James Taylor
>            Priority: Major
>              Labels: SFDC, localIndex
>             Fix For: 4.14.0, 5.0.0
>
>         Attachments: PHOENIX-3941_v1.patch, PHOENIX-3941_v2.patch, 
> PHOENIX-3941_v3.patch, PHOENIX-3941_v4.patch
>
>
> Had a good offline conversation with [~ndimiduk] at PhoenixCon about local 
> indexes. Depending on the query, we can often times prune the regions we need 
> to scan over based on the where conditions against the data table pk. For 
> example, with a multi-tenant table, we only need to scan the regions that are 
> prefixed by the tenant ID.
> We can easily get this information from the compilation of the query against 
> the data table (which we always do), through the 
> statementContext.getScanRanges() structure. We'd just want to keep a pointer 
> to the data table QueryPlan from the local index QueryPlan.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to