Re: Multiple Concurrent Updates of Shared Resource Counter

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

In response to

Browse pgsql-performance by date

  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