> That second query may not be the best, as it will probably seqscan and
> grab all the pins before only returning the first one ...
A partial index where USED_BY is null would eliminate the need for the
seqscan on the table...
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 72
In response to "Bobus" <[EMAIL PROTECTED]>:
> Hi,
>
> We are in the process of porting an application from SQL Server to
> PostgresQL.
>
> We have a table which contains a bunch of prepaid PINs. What is the
> best way to fetch the next available unique pin from the table in a
> high-traffic env
> We are in the process of porting an application from SQL Server to
> PostgresQL.
>
> We have a table which contains a bunch of prepaid PINs. What is the
> best way to fetch the next available unique pin from the table in a
> high-traffic environment with lots of concurrent requests?
>
> For ex
On Sun, Oct 29, 2006 at 08:32:12AM -0800, Bobus wrote:
> 10 users request a pin at the same time. What is the easiest/best way
> to ensure that the 10 users will get 10 unique pins, while eliminating
> any waiting?
What are you doing that holds locks for so long? If you do a select for
update, ta
I think we've figured out a way to implement the equivalent of a
READPAST hint in a function.
The basic idea is to loop until we find the next available unlocked
row, using the lock_not_available exception to determine if the record
is locked or not. Our early testing seems to indicate that this
