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] [Commented] (PHOENIX-852) Optimize child/parent foreign key joins
Date Fri, 15 Aug 2014 23:09:18 GMT

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

Maryann Xue commented on PHOENIX-852:
-------------------------------------

[~jamestaylor] Just realized one thing: Some child-to-parent joins will cover a full range
of PKs, for example, an employee basic info table joining a an employee payroll table on employee_id.
Thus, this optimization would be an extra overhead. So I'd like to add a switch and I'm thinking
of two options:
1. hint
2. a limit on the size of the value set, say, if too many point look-ups, we simply do a full
scan.

What do you think? either of them or both? if (2), what default limit value would be reasonable?

> 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