> 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
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 environment with lots of concurrent requests?
For example, our
