[
https://issues.apache.org/jira/browse/HIVE-24450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242383#comment-17242383
]
David Mollitor commented on HIVE-24450:
---------------------------------------
[~aasha] [~pvargacl] [~anishek],
Thanks for the review! That is unfortunate (re: performance) but thank you for
clarifying. Can you please take a look at HIVE-24463 ? I have added a special
case for MySQL to better performance and I have changed the code so that
incrementing by 1 is hardcoded. As it is currently written, the code makes the
reader believe that the counter can be incremented by an arbitrary amount.
> DbNotificationListener Request Notification IDs in Batches
> ----------------------------------------------------------
>
> Key: HIVE-24450
> URL: https://issues.apache.org/jira/browse/HIVE-24450
> Project: Hive
> Issue Type: Improvement
> Reporter: David Mollitor
> Assignee: David Mollitor
> Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Every time a new notification event is logged into the database, the sequence
> number for the ID of the even is incremented by one. It is very standard in
> database design to instead request a block of IDs for each fetch from the
> database. The sequence numbers are then handed out locally until the block
> of IDs is exhausted. This allows for fewer database round-trips and
> transactions, at the expense of perhaps burning a few IDs.
> Burning of IDs happens when the server is restarted in the middle of a block
> of sequence IDs. That is, if the HMS requests a block of 10 ids, and only
> three have been assigned, after the restart, the HMS will request another
> block of 10, burning (wasting) 7 IDs. As long as the blocks are not too
> small, and restarts are infrequent, then few IDs are lost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
