[
https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113205#comment-14113205
]
James Taylor commented on PHOENIX-852:
--------------------------------------
That's a nice improvement, [~maryannxue]!
Regarding the constants to use (since you don't have these yet), I don't think
it should matter which ones you use as long as they're not null. You might need
to supply two values (to prevent it being turned into an equality expression),
but if you invoke the WhereOptimizer directly, I don't think you'll even need
to do this.
FYI, [~kbuzsaki] is working on moving the minMaxRange into ScanRanges (which I
believe may help). I'm hoping you can get what you need from the ScanRanges
produced by calling WhereOptimizer.pushKeyExpressionsToScan(). If the
ScanRanges.getRanges() is populated with the constant expression you supplied,
you know it is optimized. You'll likely need to add an access for the slotSpan
member variable too - that'll tell you how many columns were optimized.
> 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)
