From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Concurrency issue under very heay loads |
Date: | 2009-07-17 14:29:25 |
Message-ID: | 1247840965.9349.4.camel@ayaki |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
On Wed, 2009-07-15 at 22:34 -0700, John R Pierce wrote:
> sounds like you should be using a SERIAL (which is implemented as an
> INTEGER or BIGINT field with an associated SEQUENCE), as these DO work
> just fine under heavy concurrency without any gotchas.
There is one gotcha, though we're all so used to it (and/or never
would've thought to care about it) as to forget it:
With a SEQUENCE, as produced by the SERIAL pseudo-type, values
may be skipped if a transaction rolls back. That includes automatic
rollback on error or disconnect, not just explicit ROLLBACK of course.
If you're using sequences to generate synthetic keys that's exactly what
you want; you don't care about gaps and you want it fast and
concurrency-friendly.
If your application can't cope with gaps in the sequence then either (a)
fix it so it can, or (b) search this mailing list for gapless sequence
implementations and use one of them. Beware the nasty performance
implications.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | John | 2009-07-17 14:31:42 | Re: something to suggest indexes |
Previous Message | Sharma, Sid | 2009-07-17 14:17:15 | Re: Idle in transaction |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-07-17 14:32:06 | Re: [PERFORM] Concurrency issue under very heay loads |
Previous Message | Kevin Grittner | 2009-07-17 14:14:05 | Re: cluster index on a table |