[ 
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maryann Xue updated PHOENIX-852:
--------------------------------

    Attachment: 852-2.patch

Added 2 hints: RANGE_SCAN_HASH_JOIN, SKIP_SCAN_HASH_JOIN

1) When RANGE_SCAN_HASH_JOIN is specified, we do BETWEEN-AND clause for RHS 
values.

2) When no hint is available and RHS does not have filters, we do BETWEEN-AND 
clause for RHS values.

3) When no hint is available and RHS has filters, we do IN clause for RHS 
values, and leave the decision of skip-scan vs. range-scan to 
WhereOptimizer.setScanFilter() and ScanRanges.useSkipScanFilter().

4) When SKIP_SCAN_HASH_JOIN is available, we do IN clause for RHS values, and 
force use of skip-scan in WhereOptimizer.setScanFilter().

> 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)

Reply via email to