[
https://issues.apache.org/jira/browse/DRILL-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543918#comment-16543918
]
Timothy Farkas commented on DRILL-6606:
---------------------------------------
The root cause is not a fundamental issue with sniffing batches, it is just a
minor logic error. The issue is that the upstream operators send join an
OK_NEW_SCHEMA (without data) and then NONE without any data. This is expected
since we are doing limit 0 in the subqueries. However in this case we don't
build the schema for the HashJoin operator due to the if statement in the first
line of HashJoinBatch.buildSchema(). The fix is to simply build the schema in
this case, which we can do since we have received the schema for the upstream
operators when they sent us OK_NEW_SCHEMA.
> 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)
