Comments on: Obtaining a block of ids from a sequence in PostgreSQL http://www.misuse.org/science/2007/08/07/obtaining-a-block-of-ids-from-a-sequence-in-postgresql/ It would be a good idea. Fri, 08 Aug 2008 00:31:33 +0000 http://wordpress.org/?v=2.5.1 By: Adam Tomjack http://www.misuse.org/science/2007/08/07/obtaining-a-block-of-ids-from-a-sequence-in-postgresql/#comment-3175 Adam Tomjack Wed, 21 May 2008 19:05:12 +0000 http://www.misuse.org/science/2007/08/07/obtaining-a-block-of-ids-from-a-sequence-in-postgresql/#comment-3175 Here's the best way I've found: SELECT nextval('propery_id_seq') FROM generate_series(1, n) It's simple, relatively fast, and it works, guaranteed. No wastage either. If you need tens of thousands of values instantly, then your method would work if you had a mutex: <pre><code>-- One time only: CREATE TABLE alter_seq_cache_lock(); -- To allocate ids: BEGIN; LOCK TABLE alter_seq_cache_lock IN EXCLUSIVE MODE; ALTER SEQUENCE ... 500 SELECT nextval... ALTER SEQUENCE ... 1 COMMIT; </code></pre> Then you only need to make sure that you don't change the sequence cache number without taking the lock. For multiple sequences, insert rows into the lock table and use ROW EXCLUSIVE locking. There's a similar trick with setval() that still wouldn't work <code><pre>BEGIN; LOCK TABLE ... id_range_min := nextval('seq'); id_range_max := setval('seq', id_range_min+n) ; max_id := SELECT max(id) FROM table WHERE id<id_range_max; id_range_min := max(max_id, id_range_min) COMMIT; </code></pre> This avoids wastage. SELECT attempts to defeats interlopers who only want one id, but somebody could do a nextval() after yours, but before your setval(), then if you finish before they insert, your SELECT doesn't notice that they did anything, so you'd have a conflict. Here’s the best way I’ve found:
SELECT nextval(’propery_id_seq’) FROM generate_series(1, n)

It’s simple, relatively fast, and it works, guaranteed. No wastage either.

If you need tens of thousands of values instantly, then your method would work if you had a mutex:

-- One time only:
CREATE TABLE alter_seq_cache_lock();
-- To allocate ids:
BEGIN;
LOCK TABLE alter_seq_cache_lock IN EXCLUSIVE MODE;
ALTER SEQUENCE ... 500
SELECT nextval...
ALTER SEQUENCE ... 1
COMMIT;

Then you only need to make sure that you don’t change the sequence cache number without taking the lock. For multiple sequences, insert rows into the lock table and use ROW EXCLUSIVE locking.

There’s a similar trick with setval() that still wouldn’t work

BEGIN;
LOCK TABLE ...
id_range_min := nextval('seq');
id_range_max := setval('seq', id_range_min+n) ;
max_id := SELECT max(id) FROM table WHERE id<id_range_max;
id_range_min := max(max_id, id_range_min)
COMMIT;


This avoids wastage. SELECT attempts to defeats interlopers who only want one id, but somebody could do a nextval() after yours, but before your setval(), then if you finish before they insert, your SELECT doesn’t notice that they did anything, so you’d have a conflict.

]]>