| From: | Oscar Tuscon <obtuse(at)bmwe30(dot)net> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Sequence Question DOH! |
| Date: | 2004-08-06 18:10:41 |
| Message-ID: | 20040806181041.9C43AAD5E@sitemail.everyone.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Oscar - if you're still interested in grabbing variable ranges of
sequence-id's then I had an idea. Just multiply nextval() by 1000 (or
whatever) and use however many you need. You'll want to set the maximum
for the sequence correspondingly lower.
--
Richard Huxton
Archonet Ltd
Thanks Richard,
I'd considered using an approach as you suggest, but I need long term high volume scalability and don't want to waste sequence values. Not that 2**64 will happen anytime soon...
What I did was to use my existing shm subsystem, which controls accesses with semaphores, and allocated a lock obj. I just modified my sequence accessor (which was already abstracted to keep db independence) to lock/unlock around sequence nextval/setval. Since the majority of my sequence requirements are for batches I wound up with about a 30% net app performance improvement (and about 500x in the sequence accessing!)
Oscar
_____________________________________________________________
The BMW E30 community on the web---> http://www.bmwe30.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2004-08-06 18:17:52 | Re: Slow after VACUUM, fast after DROP-CREATE INDEX |
| Previous Message | Joshua D. Drake | 2004-08-06 17:55:51 | Re: replication |