> Have you considered creating a sequence object with a cache size of 100?
>
> CREATE SEQUENCE id CACHE 100;
The cache resides at the connection level (ie, psql or equivalent).
If the front end is a web engine which does not use persistent connections,
wouldn't that waste a lot of sequence values?
The organization is already committed to an eight digit ID number from
its legacy environment, so I've got to be at least a little parsimonious
when allocating sequence value/ID's.
The need to allocate a block of sequence values is the exception in this
application, not the rule.
Another suggestion was made to use multiple sequences, presumably so that
blocks are allocated from one range and individual values from the other.
I don't think that resolves the problem, as in theory there could just
as easily be more than one user simutaneously requesting blocks of values
as users simultaneously requesting a single value.
One possibility I have already considered is using a table lock (probably
on a dummy table) for the duration of the interval during which individual
or blocks of sequence numbers are being requested.
For those curious, this application is for the United States Chess
Federation. They're a small enough organization that the concurrent
access issue for sequence blocks is more of a theoretical issue than a
practical one . It is probably going to be more of an issue when I
start considering ways to lock rows against simultaneous update,
especially if we use a web-based front end for a query/maintenance tool.
--
Mike Nolan