[jira] [Created] (HIVE-24210) PartitionManagementTask fails if one of tables dropped after fetch TableMeta

2020-09-29 Thread Naresh P R (Jira)
Naresh P R created HIVE-24210:
-

 Summary: PartitionManagementTask fails if one of tables dropped 
after fetch TableMeta
 Key: HIVE-24210
 URL: https://issues.apache.org/jira/browse/HIVE-24210
 Project: Hive
  Issue Type: Bug
Reporter: Naresh P R
Assignee: Naresh P R


 
{code:java}
2020-09-21T10:45:15,875 ERROR [pool-4-thread-150]: 
metastore.PartitionManagementTask (PartitionManagementTask.java:run(163)) - 
Exception while running partition discovery task for table: null
org.apache.hadoop.hive.metastore.api.NoSuchObjectException: 
hive.default.test_table table not found
 at 
org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.get_table_core(HiveMetaStore.java:3391)
 
 at 
org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.getTableInternal(HiveMetaStore.java:3315)
 
 at 
org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.get_table_req(HiveMetaStore.java:3291)
 
 at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 
 at java.lang.reflect.Method.invoke(Method.java:498) 
 at 
org.apache.hadoop.hive.metastore.RetryingHMSHandler.invokeInternal(RetryingHMSHandler.java:147)
 
 at 
org.apache.hadoop.hive.metastore.RetryingHMSHandler.invoke(RetryingHMSHandler.java:108)
 
 at com.sun.proxy.$Proxy30.get_table_req(Unknown Source) ~[?:?]
 at 
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.getTable(HiveMetaStoreClient.java:1804)
 
 at 
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.getTable(HiveMetaStoreClient.java:1791)
 
 at 
org.apache.hadoop.hive.metastore.PartitionManagementTask.run(PartitionManagementTask.java:130){code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (HIVE-24209) Search argument conversion is incorrect for NOT BETWEEN operation when vectorization is enabled

2020-09-29 Thread Ganesha Shreedhara (Jira)
Ganesha Shreedhara created HIVE-24209:
-

 Summary: Search argument conversion is incorrect for NOT BETWEEN 
operation when vectorization is enabled
 Key: HIVE-24209
 URL: https://issues.apache.org/jira/browse/HIVE-24209
 Project: Hive
  Issue Type: Bug
Reporter: Ganesha Shreedhara
Assignee: Ganesha Shreedhara


We skipped adding GenericUDFOPNot UDF in filter expression for NOT BETWEEN 
operation when vectorization is enabled because of the improvement done as part 
of HIVE-15884. But, this is not handled during the conversion of filter 
expression to search argument due to which incorrect predicate gets pushed down 
to storage layer that leads to incorrect splits generation and incorrect 
result. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (HIVE-24208) LLAP: query job stuck due to race conditions

2020-09-29 Thread Yuriy Baltovskyy (Jira)
Yuriy Baltovskyy created HIVE-24208:
---

 Summary: LLAP: query job stuck due to race conditions
 Key: HIVE-24208
 URL: https://issues.apache.org/jira/browse/HIVE-24208
 Project: Hive
  Issue Type: Bug
  Components: Hive
Affects Versions: 2.3.4
Reporter: Yuriy Baltovskyy
Assignee: Yuriy Baltovskyy


When issuing an LLAP query, sometimes the TEZ job on LLAP server never ends and 
it never returns the data reader.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (HIVE-24207) LimitOperator can leverage ObjectCache to bail out quickly

2020-09-29 Thread Rajesh Balamohan (Jira)
Rajesh Balamohan created HIVE-24207:
---

 Summary: LimitOperator can leverage ObjectCache to bail out quickly
 Key: HIVE-24207
 URL: https://issues.apache.org/jira/browse/HIVE-24207
 Project: Hive
  Issue Type: Improvement
Reporter: Rajesh Balamohan


{noformat}
select  ss_sold_date_sk from store_sales, date_dim where date_dim.d_year in 
(1998,1998+1,1998+2) and store_sales.ss_sold_date_sk = date_dim.d_date_sk limit 
100;

 select distinct ss_sold_date_sk from store_sales, date_dim where 
date_dim.d_year in (1998,1998+1,1998+2) and store_sales.ss_sold_date_sk = 
date_dim.d_date_sk limit 100;

 {noformat}

Queries like the above generate a large number of map tasks. Currently they 
don't bail out after generating enough amount of data. 

It would be good to make use of ObjectCache & retain the number of records 
generated. LimitOperator/VectorLimitOperator can bail out for the later tasks 
in the operator's init phase itself. 

https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/exec/vector/VectorLimitOperator.java#L57

https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/exec/LimitOperator.java#L58



--
This message was sent by Atlassian Jira
(v8.3.4#803005)