[
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111059#comment-14111059
]
James Taylor commented on PHOENIX-852:
--------------------------------------
My top level point is to make sure we have a common API in WhereOptimizer as
otherwise it'll be difficult to maintain.
Just refactor WhereOptimizer.pushKeyExpressionsToScan() to return the info you
need. The main thing it produces is a ScanRanges which will give you everything
you need. If ScanRanges.useSkipScan() is false, then you won't/can't do the
optimization.
My first thought is to have something like this:
{code}
public static ScanRanges pushKeyExpressionsToScan(StatementContext context,
FilterableStatement statement,
Expression whereClause, Set<Expression> extractNodes) {
{code}
This function wouldn't call context.setScanRanges(), but just return it
instead. And it wouldn't do this bit at the end:
{code}
if (whereClause == null) {
return null;
} else {
return whereClause.accept(new
RemoveExtractedNodesVisitor(extractNodes));
}
{code}
Instead you'd maintain a different function with the original signature that
would do this part:
{code}
context.setScanRanges(scanRanges);
if (whereClause == null) {
return null;
} else {
return whereClause.accept(new
RemoveExtractedNodesVisitor(extractNodes));
}
{code}
and change ScanRanges to pass in the minMaxRange in the constructor instead and
context.setScanRanges() can access it from ScanRanges instead.
> Optimize child/parent foreign key joins
> ---------------------------------------
>
> Key: PHOENIX-852
> URL: https://issues.apache.org/jira/browse/PHOENIX-852
> Project: Phoenix
> Issue Type: Improvement
> Reporter: James Taylor
> Assignee: Maryann Xue
> Attachments: 852-2.patch, 852.patch, PHOENIX-852.patch
>
>
> Often times a join will occur from a child to a parent. Our current algorithm
> would do a full scan of one side or the other. We can do much better than
> that if the HashCache contains the PK (or even part of the PK) from the table
> being joined to. In these cases, we should drive the second scan through a
> skip scan on the server side.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
