[
https://issues.apache.org/jira/browse/HIVE-17683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494227#comment-16494227
]
Eugene Koifman commented on HIVE-17683:
---------------------------------------
I agree that only Sink/Scan need to be annotated, but I think a single
TableScan may read multiple Partitions of a table. So {{select * from T where
p in (1,2)}} where 'p' is a partition column, I think should get 2 Shared
partition locks. So it doesn't quite map 1-1. Also, we don't have this yet,
but I'd like to add in the future Intention locks, where a an S lock on a
partition would cause an IS lock on parent table and DB objects. Also, perhaps
down the road we'll add support for finer grained locking, like locking
individual buckets of a bucketed table - buckets are not represented in the QP
at all.
So I think to keep things flexible and simple, I'd suggest adding support for
"explain locks select a from foo", that will simply dump the locks that will be
acquired as a table with 2 columns (resource name like cat.db.table.part, lock
Type). This would be very useful to users. I'm not even sure we need to
attach this output to the Plan output.
I think HIVE-18948 may be a lot of work.
> Annotate Query Plan with locking information
> --------------------------------------------
>
> Key: HIVE-17683
> URL: https://issues.apache.org/jira/browse/HIVE-17683
> Project: Hive
> Issue Type: New Feature
> Components: Transactions
> Reporter: Eugene Koifman
> Assignee: Igor Kryvenko
> Priority: Critical
>
> Explore if it's possible to add info about what locks will be asked for to
> the query plan.
> Lock acquisition (for Acid Lock Manager) is done in
> DbTxnManager.acquireLocks() which is called once the query starts running.
> Would need to refactor that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
