From: | Cédric Villemain <cedric(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Cc: | Nir Zilberman <nirz(at)checkpoint(dot)com> |
Subject: | Re: Multiple Concurrent Updates of Shared Resource Counter |
Date: | 2012-06-08 10:59:53 |
Message-ID: | 201206081259.57036.cedric@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Le jeudi 7 juin 2012 09:53:48, Nir Zilberman a écrit :
> Hi.
>
> We are handling multiple concurrent clients connecting to our system -
> trying to get a license seat (each license has an initial capacity of
> seats). We have a table which keeps count of the acquired seats for each
> license. When a client tries to acquire a seat we first make sure that the
> number of acquired seats is less than the license capacity. We then
> increase the number of acquired seats by 1.
>
> Our main problem here is with the acquired seats table.
> It is actually a shared resource which needs to be updated concurrently by
> multiple transactions.
>
> When multiple transactions are running concurrently - each transaction
> takes a long time to complete because it waits on the lock for the shared
> resource table.
>
> Any suggestions for better implementation/design of this feature would be
> much appreciated.
maybe you can manage something around UNIQUE (license_id,license_seat_number).
It depends of what you achieve, and the tables structures you have.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Voras | 2012-06-08 11:00:11 | Re: Seqscan slowness and stored procedures |
Previous Message | Cédric Villemain | 2012-06-08 10:36:03 | Re: Tablespaces and query planning |