On Nov 3, 2009, at 9:31 PM, Tom Lane wrote:
Brian Karlak zen...@metaweb.com 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
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 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
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
Tom --
Thanks for the pointers and advice. We've started by doubling
max_locks and halving shared_buffers, we'll see how it goes.
Brian
On Oct 10, 2009, at 7:56 PM, Tom Lane wrote:
Brian Karlak zen...@metaweb.com writes:
out of shared memory HINT: You might need to increase
Hello All --
I have implemented table partitioning in order to increase performance
in my database-backed queuing system. My queue is partitioned by
job_id into separate tables that all inherit from a base queue table.
Things were working swimmingly until my system started managing
