[jira] [Comment Edited] (IMPALA-9281) Inferred predicates not assigned to scan nodes when views are involved

2020-01-16 Thread Fang-Yu Rao (Jira)


[ 
https://issues.apache.org/jira/browse/IMPALA-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17017296#comment-17017296
 ] 

Fang-Yu Rao edited comment on IMPALA-9281 at 1/16/20 4:55 PM:
--

After some initial investigation, I found that the for-loop at 
[https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1754-L1780]
 in the method {{getBoundPredicates()}} of {{Analyzer.java}} did not create an 
inferred predicate for the query in the following according to the log file 
{{impalad.INFO}}. This is the Query 1 described in the problem description 
above. Note that we need to change the log level of 
{{org.apache.impala.analysis.Analyzer}} to {{TRACE}} at 
[http://localhost:25000/log_level].
{code:java}
select * 
from default.myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.table_source = 'ONE' 
and a.table_source = b.table_source_a;
{code}
On the other hand, we could find some inferred predicates after executing the 
following query.
{code:java}
select * 
from default.myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.c2 = b.c2a 
and a.c2 = 'one';
{code}
Specifically, we could find the following line in {{impalad.INFO}}. It turns 
out an inferred predicate {{pta1.c2a = 'one'}} was generated.
{code:java}
I0116 08:32:04.089465 21718 Analyzer.java:1750] 
ac4181dbf41da68e:c53b028e] new pred: default.pta1.c2a = 'one' 
BinaryPredicate{op==, SlotRef{label=default.pta1.c2a, path=c2a, type=STRING, 
id=11} StringLiteral{value=one}, isInferred=true}
{code}
According to 
[https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/planner/SingleNodePlanner.java#L1422]
 and 
[https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/planner/SingleNodePlanner.java#L1428],
 the list of inferred predicates {{conjuncts}} will later be fed into 
Analyzer.createEquivConjuncts(). If the inferred predicate(s) is(are) not 
correctly generated, then it seems that {{Analyzer.createEquivConjuncts()}} 
would not produce a plan that takes into consideration the inferred 
predicate(s) we expected, e.g., "{{b.table_source_a = 'ONE'}}".

The only difference between those 2 queries above is that the column involved 
in the first query, i.e., {{a.table_source}}, is a constant-valued column, 
whereas the column involved in the second query is not. Hence, we may need to 
figure out how the planner performs predicate inference under these 2 scenarios.




was (Author: fangyurao):
After some initial investigation, I found that the for-loop at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1754-L1780
 in the method {{getBoundPredicates()}} of {{Analyzer.java}} did not create an 
inferred predicate for the query in the following according to the log file 
{{impalad.INFO}}. This is the Query 1 described in the problem description 
above.

{code:java}
select * 
from default.myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.table_source = 'ONE' 
and a.table_source = b.table_source_a;
{code}

On the other hand, we could find some inferred predicates after executing the 
following query.
{code:java}
select * 
from default.myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.c2 = b.c2a 
and a.c2 = 'one';
{code}
Specifically, we could find the following line in {{impalad.INFO}}. It turns 
out an inferred predicate {{pta1.c2a = 'one'}} was generated.
{code:java}
I0116 08:32:04.089465 21718 Analyzer.java:1750] 
ac4181dbf41da68e:c53b028e] new pred: default.pta1.c2a = 'one' 
BinaryPredicate{op==, SlotRef{label=default.pta1.c2a, path=c2a, type=STRING, 
id=11} StringLiteral{value=one}, isInferred=true}
{code}

According to 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/planner/SingleNodePlanner.java#L1422
 and 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/planner/SingleNodePlanner.java#L1428,
 the list of inferred predicates {{conjuncts}} will later be fed into 
Analyzer.createEquivConjuncts(). If the inferred predicate(s) is(are) not 
correctly generated, then it seems that {{Analyzer.createEquivConjuncts()}} 
would not produce a plan that takes into consideration the inferred 
predicate(s).


> Inferred predicates not assigned to scan nodes when views are involved
> --
>
> Key: IMPALA-9281
> URL: https://issues.apache.org/jira/browse/IMPALA-9281
> Project: IMPALA
>  Issue Type: Bug
>  Components: Frontend
>Affects Versions: Impala 3.4.0
>Reporter: Fang-Yu Rao
>Assignee: Fang-Yu Rao
>Priority: Major
> Attachments: profile_query_1_parquet.txt, profile_query_2_parquet.txt
>
>

[jira] [Comment Edited] (IMPALA-9281) Inferred predicates not assigned to scan nodes when views are involved

2020-01-15 Thread Fang-Yu Rao (Jira)


[ 
https://issues.apache.org/jira/browse/IMPALA-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016353#comment-17016353
 ] 

Fang-Yu Rao edited comment on IMPALA-9281 at 1/16/20 12:08 AM:
---

After some initial investigation, I found that the field of 
{{assignedConjunctsByTupleId}} of {{Analyzer}}, which according to the comment 
stores all registered inferred conjuncts is always empty throughout every query 
described above 
(https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L358-L362).

Moreover, the method {{createInferredEqPred()}} at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1364-L1375
 has never been called during the planning.

In the following I also provide the queries I have tested.

{code:java}
select * 
from myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.c2 = b.c2a 
and a.c2 = 'one';
{code}
I expected to see an inferred predicate of {{b.c2a = 'one'}} for the query 
above but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c1 = pta1.c1a  
and pt1.c1 = 1;
{code}
I expected to see an inferred predicate of {{pta1.c1a = 1}} for the query above 
but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c2 = pta1.c2a 
and pt1.c2 = 'one';
{code}
I expected to see an inferred predicate of {{pta1.c2a = 'one'}} for the query 
above but did not see it after the planning.



was (Author: fangyurao):
After some initial investigation, I found that the field of 
{{assignedConjunctsByTupleId}} of {{Analyzer}}, which according to the comment 
stores all registered inferred conjuncts is always empty throughout every query 
described above 
(https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L358-L362).

Moreover, the method {{createInferredEqPred()}} at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1364-L1375
 has never been called during the planning.

In the following I also provide the queries I have tested.

{code:java}
select * 
from myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.c2 = b.c2a 
and a.c2 = 'one';
{code}
I expected to see an inferred predicate of {{b.c2a = 'one'}} for the query 
above but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c2 = pta1.c2a 
and pt1.c2 = 'one';
{code}
I expected to see an inferred predicate of {{pta1.c2a = 'one'}} for the query 
above but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c1 = pta1.c1a  
and pt1.c1 = 1;
{code}
I expected to see an inferred predicate of {{pta1.c1a = 1}} for the query above 
but did not see it after the planning.



> Inferred predicates not assigned to scan nodes when views are involved
> --
>
> Key: IMPALA-9281
> URL: https://issues.apache.org/jira/browse/IMPALA-9281
> Project: IMPALA
>  Issue Type: Bug
>  Components: Frontend
>Affects Versions: Impala 3.4.0
>Reporter: Fang-Yu Rao
>Assignee: Fang-Yu Rao
>Priority: Major
> Attachments: profile_query_1_parquet.txt, profile_query_2_parquet.txt
>
>
> When a query involves the join of views each created based on multiple 
> tables, the inferred predicate(s) is(are) not assigned to the scan node(s). 
> This issue is/seems related to 
> https://issues.apache.org/jira/browse/IMPALA-4578#.
> In the following a minimum example to reproduce the phenomenon.
> {code:java}
> CREATE TABLE default.pt1 (
>c1 INT,
>c2 STRING
> ) 
> STORED AS PARQUET;
> insert into pt1 values (1, 'one');
> CREATE TABLE default.pt2 (
>c1 INT,
>c2 STRING
> ) 
> STORED AS PARQUET;
> insert into pt2 values (2, 'two');
> CREATE TABLE default.pta1 (
>c1a INT, 
>c2a STRING
> )
> STORED AS PARQUET;
> insert into pta1 values (1,'one');
> CREATE TABLE default.pta2 (
>c1a INT, 
>c2a STRING
> )
> STORED AS PARQUET;
> insert into pta2 values (2,'two');
> CREATE VIEW myview_1_on_2_parquet_tables AS 
> SELECT 'ONE' table_source, c1, c2 FROM `default`.pt1 
> UNION ALL 
> SELECT 'TWO' table_source, c1, c2 FROM `default`.pt2;
> CREATE VIEW myview_2_on_2_parquet_tables AS  
> SELECT 'ONE' table_source_a, c1a, c2a FROM `default`.pta1 
> UNION ALL 
> SELECT 'TWO' table_source_a, c1a, c2a FROM `default`.pta2;
> {code}
> For easy reference, the contents of tables {{pt1}}, {{pt2}}, {{pta1}}, 
> {{pta2}}, and views {{myview_1_on_2_tables}}, {{myview_2_on_2_tables}} are 
> also given as follows.
> Contents of table {{pt1}} afterwards:
> {code:java}
> ++-+
> | c1 | c2  |
> ++-+
> | 1  | one |
> ++-+
> {code}
> Contents of 

[jira] [Comment Edited] (IMPALA-9281) Inferred predicates not assigned to scan nodes when views are involved

2020-01-15 Thread Fang-Yu Rao (Jira)


[ 
https://issues.apache.org/jira/browse/IMPALA-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016353#comment-17016353
 ] 

Fang-Yu Rao edited comment on IMPALA-9281 at 1/16/20 12:08 AM:
---

After some initial investigation, I found that the field of 
{{assignedConjunctsByTupleId}} of {{Analyzer}}, which according to the comment 
stores all registered inferred conjuncts is always empty throughout every query 
described above 
(https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L358-L362).

Moreover, the method {{createInferredEqPred()}} at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1364-L1375
 has never been called during the planning.

In the following I also provide the queries I have tested.

{code:java}
select * 
from myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.c2 = b.c2a 
and a.c2 = 'one';
{code}
I expected to see an inferred predicate of {{b.c2a = 'one'}} for the query 
above but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c1 = pta1.c1a  
and pt1.c1 = 1;
{code}
I expected to see an inferred predicate of {{pta1.c1a = 1}} for the query above 
but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c2 = pta1.c2a 
and pt1.c2 = 'one';
{code}
I expected to see an inferred predicate of {{pta1.c2a = 'one'}} for the query 
above but did not see it after the planning.



was (Author: fangyurao):
After some initial investigation, I found that the field of 
{{assignedConjunctsByTupleId}} of {{Analyzer}}, which according to the comment 
stores all registered inferred conjuncts is always empty throughout every query 
described above 
(https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L358-L362).

Moreover, the method {{createInferredEqPred()}} at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1364-L1375
 has never been called during the planning.

In the following I also provide the queries I have tested.

{code:java}
select * 
from myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.c2 = b.c2a 
and a.c2 = 'one';
{code}
I expected to see an inferred predicate of {{b.c2a = 'one'}} for the query 
above but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c1 = pta1.c1a  
and pt1.c1 = 1;
{code}
I expected to see an inferred predicate of {{pta1.c1a = 1}} for the query above 
but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c2 = pta1.c2a 
and pt1.c2 = 'one';
{code}
I expected to see an inferred predicate of {{pta1.c2a = 'one'}} for the query 
above but did not see it after the planning.


> Inferred predicates not assigned to scan nodes when views are involved
> --
>
> Key: IMPALA-9281
> URL: https://issues.apache.org/jira/browse/IMPALA-9281
> Project: IMPALA
>  Issue Type: Bug
>  Components: Frontend
>Affects Versions: Impala 3.4.0
>Reporter: Fang-Yu Rao
>Assignee: Fang-Yu Rao
>Priority: Major
> Attachments: profile_query_1_parquet.txt, profile_query_2_parquet.txt
>
>
> When a query involves the join of views each created based on multiple 
> tables, the inferred predicate(s) is(are) not assigned to the scan node(s). 
> This issue is/seems related to 
> https://issues.apache.org/jira/browse/IMPALA-4578#.
> In the following a minimum example to reproduce the phenomenon.
> {code:java}
> CREATE TABLE default.pt1 (
>c1 INT,
>c2 STRING
> ) 
> STORED AS PARQUET;
> insert into pt1 values (1, 'one');
> CREATE TABLE default.pt2 (
>c1 INT,
>c2 STRING
> ) 
> STORED AS PARQUET;
> insert into pt2 values (2, 'two');
> CREATE TABLE default.pta1 (
>c1a INT, 
>c2a STRING
> )
> STORED AS PARQUET;
> insert into pta1 values (1,'one');
> CREATE TABLE default.pta2 (
>c1a INT, 
>c2a STRING
> )
> STORED AS PARQUET;
> insert into pta2 values (2,'two');
> CREATE VIEW myview_1_on_2_parquet_tables AS 
> SELECT 'ONE' table_source, c1, c2 FROM `default`.pt1 
> UNION ALL 
> SELECT 'TWO' table_source, c1, c2 FROM `default`.pt2;
> CREATE VIEW myview_2_on_2_parquet_tables AS  
> SELECT 'ONE' table_source_a, c1a, c2a FROM `default`.pta1 
> UNION ALL 
> SELECT 'TWO' table_source_a, c1a, c2a FROM `default`.pta2;
> {code}
> For easy reference, the contents of tables {{pt1}}, {{pt2}}, {{pta1}}, 
> {{pta2}}, and views {{myview_1_on_2_tables}}, {{myview_2_on_2_tables}} are 
> also given as follows.
> Contents of table {{pt1}} afterwards:
> {code:java}
> ++-+
> | c1 | c2  |
> ++-+
> | 1  | one |
> ++-+
> {code}
> Contents of 

[jira] [Comment Edited] (IMPALA-9281) Inferred predicates not assigned to scan nodes when views are involved

2020-01-15 Thread Fang-Yu Rao (Jira)


[ 
https://issues.apache.org/jira/browse/IMPALA-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016353#comment-17016353
 ] 

Fang-Yu Rao edited comment on IMPALA-9281 at 1/16/20 12:08 AM:
---

After some initial investigation, I found that the field of 
{{assignedConjunctsByTupleId}} of {{Analyzer}}, which according to the comment 
stores all registered inferred conjuncts is always empty throughout every query 
described above 
(https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L358-L362).

Moreover, the method {{createInferredEqPred()}} at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1364-L1375
 has never been called during the planning.

In the following I also provide the queries I have tested.

{code:java}
select * 
from myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
where a.c2 = b.c2a 
and a.c2 = 'one';
{code}
I expected to see an inferred predicate of {{b.c2a = 'one'}} for the query 
above but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c2 = pta1.c2a 
and pt1.c2 = 'one';
{code}
I expected to see an inferred predicate of {{pta1.c2a = 'one'}} for the query 
above but did not see it after the planning.

{code:java}
select * 
from pt1, pta1 
where pt1.c1 = pta1.c1a  
and pt1.c1 = 1;
{code}
I expected to see an inferred predicate of {{pta1.c1a = 1}} for the query above 
but did not see it after the planning.




was (Author: fangyurao):
After some initial investigation, I found that the field of 
{{assignedConjunctsByTupleId}} of {{Analyzer}}, which according to the comment 
stores all registered inferred conjuncts is always empty throughout every query 
described above 
(https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L358-L362).

Moreover, the method {{createInferredEqPred()}} at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1364-L1375
 has never been called during the planning.


> Inferred predicates not assigned to scan nodes when views are involved
> --
>
> Key: IMPALA-9281
> URL: https://issues.apache.org/jira/browse/IMPALA-9281
> Project: IMPALA
>  Issue Type: Bug
>  Components: Frontend
>Affects Versions: Impala 3.4.0
>Reporter: Fang-Yu Rao
>Assignee: Fang-Yu Rao
>Priority: Major
> Attachments: profile_query_1_parquet.txt, profile_query_2_parquet.txt
>
>
> When a query involves the join of views each created based on multiple 
> tables, the inferred predicate(s) is(are) not assigned to the scan node(s). 
> This issue is/seems related to 
> https://issues.apache.org/jira/browse/IMPALA-4578#.
> In the following a minimum example to reproduce the phenomenon.
> {code:java}
> CREATE TABLE default.pt1 (
>c1 INT,
>c2 STRING
> ) 
> STORED AS PARQUET;
> insert into pt1 values (1, 'one');
> CREATE TABLE default.pt2 (
>c1 INT,
>c2 STRING
> ) 
> STORED AS PARQUET;
> insert into pt2 values (2, 'two');
> CREATE TABLE default.pta1 (
>c1a INT, 
>c2a STRING
> )
> STORED AS PARQUET;
> insert into pta1 values (1,'one');
> CREATE TABLE default.pta2 (
>c1a INT, 
>c2a STRING
> )
> STORED AS PARQUET;
> insert into pta2 values (2,'two');
> CREATE VIEW myview_1_on_2_parquet_tables AS 
> SELECT 'ONE' table_source, c1, c2 FROM `default`.pt1 
> UNION ALL 
> SELECT 'TWO' table_source, c1, c2 FROM `default`.pt2;
> CREATE VIEW myview_2_on_2_parquet_tables AS  
> SELECT 'ONE' table_source_a, c1a, c2a FROM `default`.pta1 
> UNION ALL 
> SELECT 'TWO' table_source_a, c1a, c2a FROM `default`.pta2;
> {code}
> For easy reference, the contents of tables {{pt1}}, {{pt2}}, {{pta1}}, 
> {{pta2}}, and views {{myview_1_on_2_tables}}, {{myview_2_on_2_tables}} are 
> also given as follows.
> Contents of table {{pt1}} afterwards:
> {code:java}
> ++-+
> | c1 | c2  |
> ++-+
> | 1  | one |
> ++-+
> {code}
> Contents of table {{pt2}} afterwards:
> {code:java}
> ++-+
> | c1 | c2  |
> ++-+
> | 2  | two |
> ++-+
> {code}
> Contents of table {{pta1}} afterwards:
> {code:java}
> +-+-+
> | c1a | c2a |
> +-+-+
> | 1   | one |
> +-+-+
> {code}
> Contents of table {{pta2}} afterwards:
> {code:java}
> +-+-+
> | c1a | c2a |
> +-+-+
> | 2   | two |
> +-+-+
> {code}
> Contents in {{myview_1_on_2_parquet_tables}} (union of tables {{t1}} and 
> {{t2}}):
> {code:java}
> +--++-+
> | table_source | c1 | c2  |
> +--++-+
> | ONE  | 1  | one |
> | TWO  | 2  | two |
> +--++-+
> {code}
> Contents in 

[jira] [Comment Edited] (IMPALA-9281) Inferred predicates not assigned to scan nodes when views are involved

2020-01-15 Thread Fang-Yu Rao (Jira)


[ 
https://issues.apache.org/jira/browse/IMPALA-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016353#comment-17016353
 ] 

Fang-Yu Rao edited comment on IMPALA-9281 at 1/15/20 11:22 PM:
---

After some initial investigation, I found that the field of 
{{assignedConjunctsByTupleId}} of {{Analyzer}}, which according to the comment 
stores all registered inferred conjuncts is always empty throughout every query 
described above 
(https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L358-L362).

Moreover, the method {{createInferredEqPred()}} at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1364-L1375
 has never been called during the planning.



was (Author: fangyurao):
After some initial investigation, I found that the field of 
{{assignedConjunctsByTupleId}} of {{Analyzer}}, which according to the comment 
stores all registered inferred conjuncts is always empty throughout every query 
described above 
(https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L358-L362).

Moreover, the method {{createInferredEqPred()}} at 
https://github.com/apache/impala/blob/master/fe/src/main/java/org/apache/impala/analysis/Analyzer.java#L1364-L1375
 has never been called during the planning.

Since the example provided in the problem description is Kudu specific and the 
problem we are having here is not only specific to Kudu, I will update the 
description accordingly to make it easier for us to reproduce the issue.


> Inferred predicates not assigned to scan nodes when views are involved
> --
>
> Key: IMPALA-9281
> URL: https://issues.apache.org/jira/browse/IMPALA-9281
> Project: IMPALA
>  Issue Type: Bug
>  Components: Frontend
>Affects Versions: Impala 3.4.0
>Reporter: Fang-Yu Rao
>Assignee: Fang-Yu Rao
>Priority: Major
> Attachments: profile_query_1_parquet.txt, profile_query_2_parquet.txt
>
>
> When a query involves the join of views each created based on multiple 
> tables, the inferred predicate(s) is(are) not assigned to the scan node(s). 
> This issue is/seems related to 
> https://issues.apache.org/jira/browse/IMPALA-4578#.
> In the following a minimum example to reproduce the phenomenon.
> {code:java}
> CREATE TABLE default.pt1 (
>c1 INT,
>c2 STRING
> ) 
> STORED AS PARQUET;
> insert into pt1 values (1, 'one');
> CREATE TABLE default.pt2 (
>c1 INT,
>c2 STRING
> ) 
> STORED AS PARQUET;
> insert into pt2 values (2, 'two');
> CREATE TABLE default.pta1 (
>c1a INT, 
>c2a STRING
> )
> STORED AS PARQUET;
> insert into pta1 values (1,'one');
> CREATE TABLE default.pta2 (
>c1a INT, 
>c2a STRING
> )
> STORED AS PARQUET;
> insert into pta2 values (2,'two');
> CREATE VIEW myview_1_on_2_parquet_tables AS 
> SELECT 'ONE' table_source, c1, c2 FROM `default`.pt1 
> UNION ALL 
> SELECT 'TWO' table_source, c1, c2 FROM `default`.pt2;
> CREATE VIEW myview_2_on_2_parquet_tables AS  
> SELECT 'ONE' table_source_a, c1a, c2a FROM `default`.pta1 
> UNION ALL 
> SELECT 'TWO' table_source_a, c1a, c2a FROM `default`.pta2;
> {code}
> For easy reference, the contents of tables {{pt1}}, {{pt2}}, {{pta1}}, 
> {{pta2}}, and views {{myview_1_on_2_tables}}, {{myview_2_on_2_tables}} are 
> also given as follows.
> Contents of table {{pt1}} afterwards:
> {code:java}
> ++-+
> | c1 | c2  |
> ++-+
> | 1  | one |
> ++-+
> {code}
> Contents of table {{pt2}} afterwards:
> {code:java}
> ++-+
> | c1 | c2  |
> ++-+
> | 2  | two |
> ++-+
> {code}
> Contents of table {{pta1}} afterwards:
> {code:java}
> +-+-+
> | c1a | c2a |
> +-+-+
> | 1   | one |
> +-+-+
> {code}
> Contents of table {{pta2}} afterwards:
> {code:java}
> +-+-+
> | c1a | c2a |
> +-+-+
> | 2   | two |
> +-+-+
> {code}
> Contents in {{myview_1_on_2_parquet_tables}} (union of tables {{t1}} and 
> {{t2}}):
> {code:java}
> +--++-+
> | table_source | c1 | c2  |
> +--++-+
> | ONE  | 1  | one |
> | TWO  | 2  | two |
> +--++-+
> {code}
> Contents in {{myview_2_on_2_parquet_tables}} (union of tables {{ta1}} and 
> {{ta2}}):
> {code:java}
> ++-+-+
> | table_source_a | c1a | c2a |
> ++-+-+
> | ONE| 1   | one |
> | TWO| 2   | two |
> ++-+-+
> {code}
> After creating the related tables and views described above, we consider the 
> following 2 queries.
> Query 1:
> {code:java}
> select * 
> from default.myview_1_on_2_parquet_tables a, myview_2_on_2_parquet_tables b 
> where