[
https://issues.apache.org/jira/browse/PHOENIX-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351017#comment-16351017
]
Maryann Xue commented on PHOENIX-3941:
--------------------------------------
[~jamestaylor], Unlike the single queries, join queries are optimized through
{{JoinCompiler#optimize()}}, which in turns calls {{QueryOptimizer#optimize()}}
for each join table to find out a *local* optimal plan. So when it comes the
time to compile the join query, we are already working on a index-replaced
query. So a straightforward solution might be to have the
{{JoinCompiler#optimize()}} method return a map from tableRef to dataPlan which
QueryCompiler can use later on to fill in the information.
Would you like me to do this part of the job? If yes, would you mind waiting
for PHOENIX-1556 to get in first?
BTW, finding a local optimal for each of the join tables was the best we could
do at the time when we started and there was no stats info, but now that we
have stats and the cost model ready, we are able to find out a global optimal
plan for join queries. However, the compile time could start to explode as the
number of join tables or that of the indices for each table go up. And it would
also require quite an amount of work, but it's something we can keep in mind.
> 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: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Priority: Major
> Labels: SFDC, localIndex
> Fix For: 4.14.0
>
> Attachments: PHOENIX-3941_v1.patch, PHOENIX-3941_v2.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)
