[ https://issues.apache.org/jira/browse/DRILL-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14954120#comment-14954120 ]
ASF GitHub Bot commented on DRILL-3921: --------------------------------------- Github user sudheeshkatkam commented on a diff in the pull request: https://github.com/apache/drill/pull/197#discussion_r41815788 --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/ops/OperatorContextImpl.java --- @@ -130,6 +134,60 @@ public OperatorStats getStats() { return stats; } + --- End diff -- Oops.. I completely forgot about cancellation. ExecutorService makes the code cleaner too. I changed the method to return a ListenableFuture. > Hive LIMIT 1 queries take too long > ---------------------------------- > > Key: DRILL-3921 > URL: https://issues.apache.org/jira/browse/DRILL-3921 > Project: Apache Drill > Issue Type: Bug > Components: Execution - Flow > Reporter: Sudheesh Katkam > Assignee: Sudheesh Katkam > > Fragment initialization on a Hive table (that is backed by a directory of > many files) can take really long. This is evident through LIMIT 1 queries. > The root cause is that the underlying reader in the HiveRecordReader is > initialized when the ctor is called, rather than when setup is called. > Two changes need to be made: > 1) lazily initialize the underlying record reader in HiveRecordReader > 2) allow for running a callable as a proxy user within an operator (through > OperatorContext). This is required as initialization of the underlying record > reader needs to be done as a proxy user (proxy for owner of the file). > Previously, this was handled while creating the record batch tree. -- This message was sent by Atlassian JIRA (v6.3.4#6332)