phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-852) Optimize child/parent foreign key joins
Date Thu, 28 Aug 2014 01:55:57 GMT


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

View raw message