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-1580) Support UNION ALL
Date Mon, 02 Mar 2015 02:20:04 GMT

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

Maryann Xue commented on PHOENIX-1580:
--------------------------------------

[~aliciashu] By saying temporary PTable instance, I do NOT mean a temporary HBase or Phoenix
table. It's just a schema (not the schema as in schema name / table name) for your data. The
PTable instance will be used to construct a ColumnResolver which decides how columns are compiled
to Expressions. For example, a ColumnResolver based on a PTable instance for a physical Phoenix
table will compile columns to either RowKeyColumnExpression or KeyValueColumnExpression, which
evaluate column values from HBase KVs. But in some cases, we would process raw HBase KVs and
project them into a different representation, and compiler would know how to compile the columns
into the right type of Expressions to make sure that the new data representation is interpreted
and evaluated the right way. 

Let's take a derived table case for example. Suppose we have a query like "SELECT t.c, count(*)
FROM (SELECT count(*) c FROM aTable GROUP BY a_string) AS t GROUP BY t.c". The first step
is to run the inner query, and the outer query iterator would take the ResultIterator returned
by the inner query and continue to process, like you said, in a streaming fashion. But the
outer query does not have to know how data is retrieved or processed by the inner query, but
it has to know the schema of the result returned by the inner query, or say, how each row
of the inner query should be interpreted. That schema is created at compiletime, on which
the outer query compilation is based. The temporary schema (PTable instance) here is definitely
different from the physical table "aTable", it's instead something like temporary table "t"
with one column "c".

I believe taking a closer look at the code in QueryCompiler and the FromCompiler would help
a lot in understanding this logic.

> Support UNION ALL
> -----------------
>
>                 Key: PHOENIX-1580
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1580
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Alicia Ying Shu
>            Assignee: Alicia Ying Shu
>         Attachments: unionall-wipe.patch
>
>
> Select * from T1
> UNION ALL
> Select * from T2



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message