Re: Concurrency issue under very heay loads

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

In response to

Browse pgsql-general by date

  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

Browse pgsql-performance by date

  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