[
https://issues.apache.org/jira/browse/HIVE-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300341#comment-15300341
]
Jesus Camacho Rodriguez commented on HIVE-13212:
------------------------------------------------
Removing 2.1.0 target. Please feel free to commit to branch-2.1 anyway and fix
for 2.1.0 if this happens before the release.
> locking too coarse/broad for update/delete on a pratition
> ---------------------------------------------------------
>
> Key: HIVE-13212
> URL: https://issues.apache.org/jira/browse/HIVE-13212
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 1.2.1
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
>
> create table acidTblPart (a int, b int) partitioned by (p string) clustered
> by (a) into " + BUCKET_COUNT + " buckets stored as orc TBLPROPERTIES
> ('transactional'='true')
> update acidTblPart set b = 17 where p = 1
> This acquires share_write on the table while based on p = 1 we should be able
> to figure out that only 1 partition is affected and only lock the partition
> Same should apply to DELETE
> Above is true when table is empty. If table has data, in particular it has
> p=1 partition, then only the partition is locked.
> However "update acidTblPart set b = 17 where b = 18" and the table is not
> empty, will lock every partition separately.
> For a table with 100K partitions this will be a performance issue.
> Need to look into getting a table level lock instead or build general lock
> promotion logic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
