[
https://issues.apache.org/jira/browse/HIVE-22850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034572#comment-17034572
]
Zoltan Chovan commented on HIVE-22850:
--------------------------------------
[~rajesh.balamohan] I think Peter was referring to this part:
{code:java}
StringBuilder query = new StringBuilder("select count(*) from "
+ "\"HIVE_LOCKS\" where \"HL_DB\" in (");
boolean first = true;
for (String s : dbs) {
if (first) first = false;
else query.append(", ");
query.append('\'');
query.append(s);
query.append('\'');
}
{code}
Oracle db has a limitation on how many elements can be present in and IN()
clause, if it's over 1000 the query will fail. In order to avoid that you might
consider some kind of batching for this part.
> Optimise lock acquisition in TxnHandler
> ---------------------------------------
>
> Key: HIVE-22850
> URL: https://issues.apache.org/jira/browse/HIVE-22850
> Project: Hive
> Issue Type: Improvement
> Components: Hive
> Reporter: Rajesh Balamohan
> Priority: Major
> Attachments: HIVE-22850.1.patch, HIVE-22850.2.patch,
> HIVE-22850.3.patch, Screenshot 2020-02-07 at 4.14.51 AM.jpg, jumpTableInfo.png
>
>
> With concurrent queries, time taken for lock acquisition increases
> substantially. As part of lock acquisition in the query,
> {{TxnHandler::checkLock}} gets invoked. This involves getting a mutex and
> compare the locks being requested for, with that of existing locks in
> {{HIVE_LOCKS}} table.
> With concurrent queries, time taken to do this check increase and this
> significantly increases the time taken for getting mutex for other threads
> (due to select for update). In a synthetic workload, it was in the order of
> 10+ seconds. This codepath can be optimized when all lock requests are
> SHARED_READ.
>
>
> !Screenshot 2020-02-07 at 4.14.51 AM.jpg|width=743,height=348!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
