I think in ORACLE they call it CACHE you define on SEQUENCE creation ... http://docs.oracle.com/cd/B28359_01/server.111/b28310/views002.htm#ADMIN11796
It not exactly the same since it defined on SEQUENCE definition (what I think make sense) Keep in mind that there will be gaps On Mon, May 11, 2015 at 2:42 PM, James Taylor (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/PHOENIX-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538343#comment-14538343 > ] > > James Taylor edited comment on PHOENIX-1954 at 5/11/15 6:42 PM: > ---------------------------------------------------------------- > > After talking with [~alexaraujo] and [~lhofhansl], I think I understand > what you need. > - Variation of NEXT VALUE FOR <seq> that takes an additional value that > represents the batch size for that particular call. > - The call should return the current sequence number (as it currently > does) and allocate a batch of the required size such that the sequence > values are contiguous. > > [~julianhyde] - have you ever seen this in SQL dialects? What would be the > best way to add this so that our Phoenix Calcite integration is smooth? A > built-in function is a bit awkward as you'd need to refer to the sequence > name as a string. My preference would be something like: > {code} > NEXT VALUE FOR <seq> ALLOCATE <n> > {code} > > > was (Author: jamestaylor): > After talking with [~alexaraujo] and [~lhofhansl], I think I understand > what you need. > - Variation of NEXT VALUE FOR <seq> that takes an additional value that > represents the batch size for that particular call. > - The call should return the current sequence number (as it currently > does) and allocate a batch of the required size such that the sequence > values are contiguous. > > > > Reserve chunks of numbers for a sequence > > ---------------------------------------- > > > > Key: PHOENIX-1954 > > URL: https://issues.apache.org/jira/browse/PHOENIX-1954 > > Project: Phoenix > > Issue Type: Bug > > Reporter: Lars Hofhansl > > > > In order to be able to generate many ids in bulk (for example in map > reduce jobs) we need a way to generate or reserve large sets of ids. We > also need to mix ids reserved with incrementally generated ids from other > clients. > > For this we need to atomically increment the sequence and return the > value it had when the increment happened. > > If we're OK to throw the current cached set of values away we can do > > {{NEXT VALUE FOR <seq>(,<N>)}}, that needs to increment value and return > the value it incremented from (i.e. it has to throw the current cache away, > and return the next value it found at the server). > > Or we can invent a new syntax {{RESERVE VALUES FOR <seq>, <N>}} that > does the same, but does not invalidate the cache. > > Note that in either case we won't retrieve the reserved set of values > via {{NEXT VALUE FOR}} because we'd need to be idempotent in our case, all > we need to guarantee is that after a call to {{RESERVE VALUES FOR <seq>, > <N>}}, which returns a value <M> is that the range [M, M+N) won't be used > by any other user of the sequence. My might need reserve 1bn ids this way > ahead of a map reduce run. > > Any better ideas? > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
