You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Maryann Xue (JIRA)" <ji...@apache.org> on 2014/08/14 05:04:12 UTC
[jira] [Updated] (PHOENIX-1167) Support subqueries (derived tables)
[ https://issues.apache.org/jira/browse/PHOENIX-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maryann Xue updated PHOENIX-1167:
---------------------------------
Description:
1. Semi/anti joins: including "IN / NOT IN" tests operating on non-correlated sub-queries (PHOENIX-167).
We can evaluate the sub-queries as sets and execute the outer query the same way as we now do IN clause.
2. Other non-correlated sub-queries: having a comparison operator with no modifier or a comparison operator modified by ANY, SOME or ALL (PHOENIX-1168).
a) The sub-query can/must be evaluated as a single value. (Like "= / !=" with no modifiers; Or in cases like "> / < / >= / <=" "ANY/SOME/ALL", either max() or min() can be applied to the sub-query).
b) In cases like "= / !=" "ANY / SOME / ALL", they are equivalent to category 2 queries.
3. General correlated sub-queries (PHOENIX-945):
Need more sophisticated rewriting techniques to convert them into joins.
** if none of the dependence of inner query on the outer query is equi condition, we are currently unable to handle them.
4. Nested sub-queries: having sub-queries in the FROM clause.
We are now able to handle most of them. Exceptions are PHOENIX-943, PHOENIX-944.
was:
1. Semi/anti joins: including "IN / NOT IN" tests operating on non-correlated sub-queries (PHOENIX-167).
We can evaluate the sub-queries as sets and execute the outer query the same way as we now do IN clause.
2. Other non-correlated sub-queries: having a comparison operator with no modifier or a comparison operator modified by ANY, SOME or ALL.
a) The sub-query can/must be evaluated as a single value. (Like "= / !=" with no modifiers; Or in cases like "> / < / >= / <=" "ANY/SOME/ALL", either max() or min() can be applied to the sub-query).
b) In cases like "= / !=" "ANY / SOME / ALL", they are equivalent to category 2 queries.
3. General correlated sub-queries (PHOENIX-945):
Need more sophisticated rewriting techniques to convert them into joins.
** if none of the dependence of inner query on the outer query is equi condition, we are currently unable to handle them.
4. Nested sub-queries: having sub-queries in the FROM clause.
We are now able to handle most of them. Exceptions are PHOENIX-943, PHOENIX-944.
> Support subqueries (derived tables)
> -----------------------------------
>
> Key: PHOENIX-1167
> URL: https://issues.apache.org/jira/browse/PHOENIX-1167
> Project: Phoenix
> Issue Type: Bug
> 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
>
> Original Estimate: 2,688h
> Remaining Estimate: 2,688h
>
> 1. Semi/anti joins: including "IN / NOT IN" tests operating on non-correlated sub-queries (PHOENIX-167).
> We can evaluate the sub-queries as sets and execute the outer query the same way as we now do IN clause.
> 2. Other non-correlated sub-queries: having a comparison operator with no modifier or a comparison operator modified by ANY, SOME or ALL (PHOENIX-1168).
> a) The sub-query can/must be evaluated as a single value. (Like "= / !=" with no modifiers; Or in cases like "> / < / >= / <=" "ANY/SOME/ALL", either max() or min() can be applied to the sub-query).
> b) In cases like "= / !=" "ANY / SOME / ALL", they are equivalent to category 2 queries.
>
> 3. General correlated sub-queries (PHOENIX-945):
> Need more sophisticated rewriting techniques to convert them into joins.
> ** if none of the dependence of inner query on the outer query is equi condition, we are currently unable to handle them.
> 4. Nested sub-queries: having sub-queries in the FROM clause.
> We are now able to handle most of them. Exceptions are PHOENIX-943, PHOENIX-944.
--
This message was sent by Atlassian JIRA
(v6.2#6252)