You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "Andrew Kyle Purtell (Jira)" <ji...@apache.org> on 2022/11/07 21:34:00 UTC

[jira] [Commented] (PHOENIX-6787) Server-side Sequence Update Consolidation

    [ https://issues.apache.org/jira/browse/PHOENIX-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630041#comment-17630041 ] 

Andrew Kyle Purtell commented on PHOENIX-6787:
----------------------------------------------

[~kozdemir] Taking this one too. 

> Server-side Sequence Update Consolidation
> -----------------------------------------
>
>                 Key: PHOENIX-6787
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6787
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Geoffrey Jacoby
>            Assignee: Andrew Kyle Purtell
>            Priority: Major
>             Fix For: 5.3.0
>
>
> For secondary indexes, we have optimizations so that if multiple mutations are waiting on the same row lock, all subsequent mutations can re-use the previous mutation's final state and avoid an extra Get. 
> We can apply a similar idea to Phoenix sequences. If there's a "hot" sequence with multiple requests queueing for a Sequence row lock, we can consolidate them down to one set of Get / Put operations, then satisfy them all. This change is transparent to the clients. 
> Note that if this consolidation would cause the sequence update to fail when some of the requests would have succeeded otherwise, we should not consolidate. (An example is if a sequence has cycling disabled, and the first request would not overflow, but the first and second combined would. In this case we should let the first request go through unconsolidated, and fail the second request.) 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)