Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id D6C6ED84656 for ; Fri, 8 Jun 2012 08:00:18 -0300 (ADT) Received: from moutng.kundenserver.de ([212.227.126.187]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1ScwvQ-0005Yw-TG for pgsql-performance@postgresql.org; Fri, 08 Jun 2012 11:00:18 +0000 Received: from obelix.localnet (AToulouse-556-1-160-221.w92-162.abo.wanadoo.fr [92.162.24.221]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LzleJ-1RqdUE3YdH-0154oU; Fri, 08 Jun 2012 12:59:58 +0200 From: =?iso-8859-15?q?C=E9dric_Villemain?= Reply-To: cedric@2ndquadrant.com Organization: 2ndQuadrant To: pgsql-performance@postgresql.org Subject: Re: Multiple Concurrent Updates of Shared Resource Counter Date: Fri, 8 Jun 2012 12:59:53 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-2-amd64; KDE/4.7.4; x86_64; ; ) Cc: Nir Zilberman References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3159809.0WS9EmNGKK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201206081259.57036.cedric@2ndquadrant.com> X-Provags-ID: V02:K0:AuxGU6VOGlHh1Pw2qcdRU5fvSJ6jeddJvjZ5FW+9kla DQU4soQww6JrwUaZlVsVwuynD/bHGh8omABzrTeSjGELj45yzX o3+BwtS61ArIPpWWBNbSib4VDyDiXTzs4wV1cX0gsArWcUPcSX zHsYawlO623CIm+KDx1BB0ET0Xb7f/vuGEcP+tpXlR7sLH3Vv2 e4w/Y1cEBl8CbxAWPp1nJViiWPC/rwdfMLm+tLwrarE33fU/U4 zWu8hCx7RRci0tilFSf/UKss+B4lSdaJCF//iEdGb/kntaxyjb sGxOAdE5Kkegf++4gWBYTP8/i7Xl5l4l/z7hEJrxwxcQ9I+lIZ z0DXkCuqFUh4hRAl78fBO4kmfmKQKrNPH7xok5Yrt X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/36 X-Sequence-Number: 47062 --nextPart3159809.0WS9EmNGKK Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Le jeudi 7 juin 2012 09:53:48, Nir Zilberman a =E9crit : > Hi. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Any suggestions for better implementation/design of this feature would be > much appreciated. maybe you can manage something around UNIQUE (license_id,license_seat_numbe= r). It depends of what you achieve, and the tables structures you have. =2D-=20 C=E9dric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - D=E9veloppement, Expertise et Formation --nextPart3159809.0WS9EmNGKK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAABAgAGBQJP0dspAAoJENsgH0yzVBebEhEH/0Av0FnTU+/e7lOUErQHZ2zK QZHTrSBXTt8cftBmEtJEffOFFoaLd33j5CWF5oHp1BXJLDxp7VkVs6vF81PAruSs BHH+/65fCFXfStgdj60hXzykO3a0QWJSZKw5gCCbqRWngaY76To0zMvvl4GEiJJk D/seGzlXjybBDCnmEbDi/HRhthlwHqENgGzN54ltBd+jLTXbJ0c2pY0VcAyc31bU e2UrBGQzXUJtmNUxNLOxhoccozir/y6w/aqWsKT5NtegmcR6SPMgftL1DOw1/bsL bUGH621WU196mcetCDxh+qfGf21zeXuD8xbeU07kw8HgYHE8DooUiqe2NQmnTlI= =e+7h -----END PGP SIGNATURE----- --nextPart3159809.0WS9EmNGKK--