hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Koifman (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-13741) TxnHandler.enqueueLockWithRetry() - optimize sql
Date Thu, 26 May 2016 17:56:12 GMT

     [ https://issues.apache.org/jira/browse/HIVE-13741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Eugene Koifman updated HIVE-13741:
----------------------------------
    Description: 
TxnHandler.enqueueLockWithRetry()  does SQL insert into 2 tables using (possibly) multiple
statements for each.  Could easily generate 1 statement for each table.

TxnHandler.addDynamicPartitions() - the insert stmt here should combing multiple rows into
single SQL stmt (but with a limit for extreme cases)

https://issues.apache.org/jira/browse/HIVE-13395?focusedCommentId=15271712&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15271712
bq. In TxnHandler.commitTxn, would it make sense to rearrange this so that the check is made
whether there are any operations that could conflict before the mutex is obtained and the
transaction id checked? If there's nothing to record in the write sets I don't see why you
need to hold the mutex or even record a commit txn id.


Note that Oracle doesn't support "insert into T values(1,2), (3,4)"

  was:
TxnHandler.enqueueLockWithRetry()  does SQL insert into 2 tables using (possibly) multiple
statements for each.  Could easily generate 1 statement for each table.

TxnHandler.addDynamicPartitions() - the insert stmt here should combing multiple rows into
single SQL stmt (but with a limit for extreme cases)

https://issues.apache.org/jira/browse/HIVE-13395?focusedCommentId=15271712&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15271712
bq. In TxnHandler.commitTxn, would it make sense to rearrange this so that the check is made
whether there are any operations that could conflict before the mutex is obtained and the
transaction id checked? If there's nothing to record in the write sets I don't see why you
need to hold the mutex or even record a commit txn id.


> TxnHandler.enqueueLockWithRetry() - optimize  sql
> -------------------------------------------------
>
>                 Key: HIVE-13741
>                 URL: https://issues.apache.org/jira/browse/HIVE-13741
>             Project: Hive
>          Issue Type: Improvement
>          Components: Metastore, Transactions
>    Affects Versions: 1.0.0
>            Reporter: Eugene Koifman
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> TxnHandler.enqueueLockWithRetry()  does SQL insert into 2 tables using (possibly) multiple
statements for each.  Could easily generate 1 statement for each table.
> TxnHandler.addDynamicPartitions() - the insert stmt here should combing multiple rows
into single SQL stmt (but with a limit for extreme cases)
> https://issues.apache.org/jira/browse/HIVE-13395?focusedCommentId=15271712&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15271712
> bq. In TxnHandler.commitTxn, would it make sense to rearrange this so that the check
is made whether there are any operations that could conflict before the mutex is obtained
and the transaction id checked? If there's nothing to record in the write sets I don't see
why you need to hold the mutex or even record a commit txn id.
> Note that Oracle doesn't support "insert into T values(1,2), (3,4)"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message