[
https://issues.apache.org/jira/browse/DRILL-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543352#comment-16543352
]
Volodymyr Vysotskyi commented on DRILL-6606:
--------------------------------------------
{{limit 0}} in subqueries is a good way of discovering schema without joining
data.
But the problem is more general. For example, if both subqueries have filters,
which filters all the input data, the information about schema also will be
lost in the case of a hash join. I think this case is more common than the case
with {{limit 0}}.
I agree with Boaz that the problem is in "early sniffing", when the schema is
built only when any data had come.
Columns have the same types as the expected types in
{{TestPreparedStatementProvider#joinOrderByQuery()}} test: {{DOUBLE}},
{{DATE}}, {{INTEGER}}.
> Hash Join returns incorrect data types when joining subqueries with limit 0
> ---------------------------------------------------------------------------
>
> Key: DRILL-6606
> URL: https://issues.apache.org/jira/browse/DRILL-6606
> Project: Apache Drill
> Issue Type: Bug
> Reporter: Bohdan Kazydub
> Assignee: Timothy Farkas
> Priority: Blocker
> Fix For: 1.14.0
>
>
> PreparedStatement for query
> {code:sql}
> SELECT l.l_quantity, l.l_shipdate, o.o_custkey
> FROM (SELECT * FROM cp.`tpch/lineitem.parquet` LIMIT 0) l
> JOIN (SELECT * FROM cp.`tpch/orders.parquet` LIMIT 0) o
> ON l.l_orderkey = o.o_orderkey
> LIMIT 0
> {code}
> is created with wrong types (nullable INTEGER) for all selected columns, no
> matter what their actual type is. This behavior reproduces with hash join
> only and is very likely to be caused by DRILL-6027 as the query works fine
> before this feature was implemented.
> To reproduce the problem you can put the aforementioned query into
> TestPreparedStatementProvider#joinOrderByQuery() test method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
