[
https://issues.apache.org/jira/browse/DRILL-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979701#comment-14979701
]
ASF GitHub Bot commented on DRILL-3623:
---------------------------------------
Github user jacques-n commented on the pull request:
https://github.com/apache/drill/pull/193#issuecomment-152056732
I'm sorry to say that I'm -1 on this change
It seems to be adding a planning rewrite rule where there should be a
simple fix execution bug. Let's just fix the execution bug.
Limit 0 should complete its execution the moment it receives a schema (as
part of fast schema). It doesn't need to receive any records. You just
described a situation where it is waiting for records from a blocking operator.
That shouldn't be the case. If there is some other real benefit to this change
after that execution bug is fixed, let's revisit in that light.
If you think I'm misunderstanding your description of the execution
behavior or the dynamics involved, please help me to better understand.
> Hive query hangs with limit 0 clause
> ------------------------------------
>
> Key: DRILL-3623
> URL: https://issues.apache.org/jira/browse/DRILL-3623
> Project: Apache Drill
> Issue Type: Bug
> Components: Storage - Hive
> Affects Versions: 1.1.0
> Environment: MapR cluster
> Reporter: Andries Engelbrecht
> Assignee: Jinfeng Ni
> Fix For: Future
>
>
> Running a select * from hive.table limit 0 does not return (hangs).
> Select * from hive.table limit 1 works fine
> Hive table is about 6GB with 330 files with parquet using snappy compression.
> Data types are int, bigint, string and double.
> Querying directory with parquet files through the DFS plugin works fine
> select * from dfs.root.`/user/hive/warehouse/database/table` limit 0;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
