phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4585) Prune local index regions used for join queries
Date Fri, 16 Feb 2018 17:27:00 GMT

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

James Taylor commented on PHOENIX-4585:
---------------------------------------

Thanks for the patch, [~maryannxue]. Here's some questions & comments:
- How about adding a UNION ALL test to make sure we're doing the pruning there too?
- If you want to combine this with PHOENIX-4614, that's fine too if you think you can get
to it soon. 
- Not a huge deal, but do you think it's confusing that we have a dataPlan member variable
on QueryCompiler but then we pass through the dataPlan to compileSingleFlatQuery for other
code paths?
- Somewhat orthogonal to this change, but our APIs are a bit confusing with the optimize call
that happens in PhoenixStatement:
{code}
                        QueryPlan plan = stmt.compilePlan(PhoenixStatement.this, Sequence.ValueOp.VALIDATE_SEQUENCE);
                        // Send mutations to hbase, so they are visible to subsequent reads.
                        // Use original plan for data table so that data and immutable indexes
will be sent
                        // TODO: for joins, we need to iterate through all tables, but we
need the original table,
                        // not the projected table, so plan.getContext().getResolver().getTables()
won't work.
                        Iterator<TableRef> tableRefs = plan.getSourceRefs().iterator();
                        connection.getMutationState().sendUncommitted(tableRefs);
                        plan = connection.getQueryServices().getOptimizer().optimize(PhoenixStatement.this,
plan);
{code}
What happens in that optimize call for joins & union all (since it seems that the optimization
happens during compile)? Should we clean that up (maybe in a separate JIRA)?
- Also related to the above, we need to ensure that {{tableRefs}} returns the original data
tables and not the index tables or we won't send over uncommitted data when transactions are
used. Do you think that's happening?


> Prune local index regions used for join queries
> -----------------------------------------------
>
>                 Key: PHOENIX-4585
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4585
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: James Taylor
>            Assignee: Maryann Xue
>            Priority: Major
>         Attachments: PHOENIX-4585.patch
>
>
> Some remaining work from PHOENIX-3941: we currently do not capture the data plan as part
of the index plan due to the way in which we rewrite the statement during join processing.
See comment here for more detail: https://issues.apache.org/jira/browse/PHOENIX-3941?focusedCommentId=16351017&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16351017



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

Mime
View raw message