From: Mario Splivalo <mario.splivalo@mobart.hr>
To: PFC <lists@peufeu.com>
Cc: Achilleus Mantzios <achill@matrix.gatewaynet.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: 'locking' the SELECTs based on indices...
Date: Thu, 23 Feb 2006 21:07:58 +0100
Message-ID: <1140725278.5002.70.camel@localhost.localdomain> (raw)
In-Reply-To: <op.s5fpo7sncigqcu@apollo13>
References: <Pine.LNX.4.44.0602231349430.15710-100000@matrix.gatewaynet.com>
<1140692542.5002.26.camel@localhost.localdomain>
<op.s5fpo7sncigqcu@apollo13>
On Thu, 2006-02-23 at 17:35 +0100, PFC wrote:
>
> > Now, If some other user want's his prize, when checking his code, if he
> > sends code for some other service then service 1, that's ok. If he's
> > sends code for the service 1 the PERFORM will wait untill I'm finished
> > with previous user.
>
> Sorry for the double post.
>
> If the rows in your table represent associations between codes and
> services that are one-use only, you could simply use UPDATE or DELETE, to
> mark the row in question as having been "consumed".
> Then, you check how many rows were deleted or updated. If it's 1, good.
> If it's 0, the code has been used already.
>
> If the code itself is one-use only, you should have a codes table and a
> codes_to_services table, with an ON DELETE CASCADE so that, when you use a
> code, you delete it from the codes table and it's "consumed" for all
> services.
Thank you for the advice, I'll consider it too.
The original idea was with UPDATE, so I could mark codes wich are used,
but the table with codes will have 10M rows in the begining, for just
one game. Later we'll have more games, with like 100M rows in the table.
UPDATEing such table, when the server is under normal load (server also
hosts some other games) is between 15 and 40 seconds. That is why I
tried to eliminate UPDATEs and go with two tables, and INSERTS into the
second table, for used codes.
Mike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: mario.splivalo@mobart.hr, lists@peufeu.com, achill@matrix.gatewaynet.com
Subject: Re: 'locking' the SELECTs based on indices...
In-Reply-To: <1140725278.5002.70.camel@localhost.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox