[
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14104987#comment-14104987
]
James Taylor edited comment on PHOENIX-852 at 8/21/14 3:34 AM:
---------------------------------------------------------------
In the absence of any hints, I think a skip scan should be done when possible
(i.e. if the leading pk columns are used, basically determined by the
ScanRanges.useSkipScan() after WhereOptimizer does it's thing). If a skip scan
is possible and the RANGE_SCAN_HASH_JOIN hint is present, then do a range scan.
If the SKIP_SCAN_HASH_JOIN is present, then do a skip scan if *some* PK keys
are being joined (doesn't make sense otherwise). This is how the SKIP_SCAN and
RANGE_SCAN hints work now.
What about the case of a partial PK match. For example, where there's a PK of
(c1,c2,c3) and only c1 and c2 are matched? Does that just depend on how it's
handled by WhereOptimizer, so when we handle that case there, we'll get it for
free here?
If all unit tests pass and you feel this is isolated enough to just joins, then
feel free to commit.
was (Author: jamestaylor):
In the absence of any hints, I think the default should be to do a skip scan
when possible (i.e. if the leading pk columns are used). If a skip scan is
possible and the RANGE_SCAN_HASH_JOIN hint is present, then do a range scan. If
the SKIP_SCAN_HASH_JOIN is present, then do a skip scan if *some* PK keys are
being joined (doesn't make sense otherwise). This is how the SKIP_SCAN and
RANGE_SCAN hints work now.
> 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.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)
