Brian Karlak writes:
> I have a simple queuing application written on top of postgres which I'm
> trying to squeeze some more performance out of.
Have you tried to write a custom PGQ consumer yet?
http://wiki.postgresql.org/wiki/PGQ_Tutorial
Regards,
--
dim
--
Sent via pgsql-performance mai
Brian Karlak writes:
> On Nov 4, 2009, at 8:47 AM, Jeff Janes wrote:
>> Why would the index scan take 1 ms two of the times it is done but 5ms
>> the third time? Isn't it the same index scan each time? Or does the
>> change in queue.status change the plan?
> The final update is a different quer
On Nov 4, 2009, at 8:47 AM, Jeff Janes wrote:
Worker daemons do a bounded, ordered, limited SELECT to grab a row,
which
they lock by setting a value in the queue.status column.
So you do a select, and then an update?
I do a select for update in a stored proc:
FOR queue_item IN
SELECT *
On Nov 3, 2009, at 9:31 PM, Tom Lane wrote:
Brian Karlak writes:
My question is this: is there some way that I can keep a cursor /
pointer / reference / whatever to the row I fetched originally, so
that I don't have to search for it again when I'm ready to write
results?
If you don't expect
On Tue, Nov 3, 2009 at 12:30 PM, Brian Karlak wrote:
> Hello All --
>
> I have a simple queuing application written on top of postgres which I'm
> trying to squeeze some more performance out of.
>
> The setup is relatively simple: there is a central queue table in postgres.
> Worker daemons do a
Brian Karlak writes:
> My question is this: is there some way that I can keep a cursor /
> pointer / reference / whatever to the row I fetched originally, so
> that I don't have to search for it again when I'm ready to write
> results?
If you don't expect any updates to the row meanwhile, c
On Nov 3, 2009, at 4:03 PM, Craig Ringer wrote:
I don't have a good answer for you there. Perhaps using Pg's locking
to
do your queueing, rather than updating a status flag, might let you
use
a cursor? Have a look at the list archives - there's been a fair bit
of
discussion of queuing mec
Brian Karlak wrote:
> The setup is relatively simple: there is a central queue table in
> postgres. Worker daemons do a bounded, ordered, limited SELECT to grab
> a row, which they lock by setting a value in the queue.status column.
You can probably do an UPDATE ... RETURNING to turn that into
Hello All --
I have a simple queuing application written on top of postgres which
I'm trying to squeeze some more performance out of.
The setup is relatively simple: there is a central queue table in
postgres. Worker daemons do a bounded, ordered, limited SELECT to
grab a row, which they
