>-Original Message-
>From: pgsql-performance-ow...@postgresql.org
>
>We use a typical counter within a transaction to generate
>order sequence number and update the next sequence number.
>This is a simple next counter - nothing fancy about it. When
>multiple clients are concurrently a
On Thu, 2009-07-16 at 00:11 -0600, Scott Marlowe wrote:
> As others have said, a serial is a good idea, HOWEVER, if you can't
> have gaps in sequences, or each customer needs their own sequence,
> then you get to lock the rows / table / etc that you're mucking with
> to make sure you don't issue t
Raji Sridar wrote:
> We use a typical counter within a transaction to generate
> order sequence number and update the next sequence number.
> This is a simple next counter - nothing fancy about it. When
> multiple clients are concurrently accessing this table and
> updating it, under extermely
On Wed, Jul 15, 2009 at 10:59 PM, Raji Sridar (raji) wrote:
> Hi,
>
> We use a typical counter within a transaction to generate order sequence
> number and update the next sequence number. This is a simple next counter -
> nothing fancy about it. When multiple clients are concurrently accessing
>
Hi,
Are you using automatic sequence increment in table?
- Original Message -
From: Raji Sridar (raji)
To: pgsql-gene...@postgresql.org ; pgsql-performance@postgresql.org
Sent: Thursday, July 16, 2009 10:29 AM
Subject: [PERFORM] Concurrency issue under very heay loads
Hi,
