phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maryann Xue (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (PHOENIX-852) Optimize child/parent foreign key joins
Date Thu, 14 Aug 2014 21:32:19 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097699#comment-14097699
] 

Maryann Xue edited comment on PHOENIX-852 at 8/14/14 9:32 PM:
--------------------------------------------------------------

Yes... guess I'm a little confused about the handling of pk columns in WhereOptimizer. Is
it that currently we can only handle cases that satisfy 1) PK positions are consecutive and
2) PK positions start from 0 (based on pk-offset)?

So before any improvement has been made to WhereOptimizer and SkipScanFilter, we only find
those join conditions that together have the leading PK columns and optimize them? For example,
table A's PK is (c0,c1,c2), and our join conditions on table A has c0 and c2. We simply include
c0 in the skip scan optimization.




was (Author: maryannxue):
Yes... guess I'm a little confused about the handling of pk columns in WhereOptimizer. Is
it that currently we can only handle cases that satisfy 1) PK positions are consecutive and
2) PK positions start from 0 (based on pk-offset)?

So before any improvement has been made to WhereOptimizer and SkipScanFilter, we only find
those join conditions that together have the leading PK columns and optimize them?



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

Mime
View raw message