[
https://issues.apache.org/jira/browse/PHOENIX-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144362#comment-14144362
]
James Taylor commented on PHOENIX-1168:
---------------------------------------
One more consideration I was thinking of: given that we know we need to solve
the many-to-many join case, do you think that having a separate code path for
the non-correlated sub-queries will make it harder to leverage the solution we
come up with for that? I imagine that the correlated sub-query code path will
go through a similar code path as the hash join code path. Do you think it's
better to put more abstraction around this now, in preparation for that? Or
should we keep going with the in-memory solution and refactor later?
I'm +1 on which ever path you think best (and this commit), though,
[~maryannxue]. Thanks for the contributions!
> Support non-correlated sub-queries in where clause having a comparison
> operator with no modifier or a comparison operator modified by ANY, SOME or
> ALL
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-1168
> URL: https://issues.apache.org/jira/browse/PHOENIX-1168
> Project: Phoenix
> Issue Type: Sub-task
> Affects Versions: 3.0.0, 4.0.0, 5.0.0
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Fix For: 3.0.0, 4.0.0, 5.0.0
>
> Attachments: 1168.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)