been a simple
update almost matched the activity of 200+ processes (which are not yet
running at full power).
Any suggestions for where to look?
On Sat, 15 Mar 2014 11:49:36 +0100, Yngve N. Pettersen
wrote:
Hi again,
A further update, and it looks like I have finally been able to &quo
eign-key constraints:
"queue_queueitems_group_id_fkey" FOREIGN KEY (group_id) REFERENCES
queue_queuerun(id) DEFERRABLE INITIALLY DEFERRED
"queue_queueitems_target_id_fkey" FOREIGN KEY (target_id) REFERENCES
queue_queuetarget(id) DEFERRABLE INITIALLY DEFERRED
On Mon, 10 Mar
the UPDATE command
UPDATE probedata2_probequeue SET "state"=E'S'
WHERE "state" = E'I' AND id IN ( .)
RETURNING id
and I have confirmed that with the built-in Django debug query information
in my test script.
On Sat, 08 Feb 2014 15:5
On Sat, 04 Jan 2014 19:40:31 +0100, Andrew Sullivan
wrote:
On Sat, Jan 04, 2014 at 07:07:08PM +0100, Yngve N. Pettersen wrote:
I tried that before, but ran into some issues, IIRC a similar looping
problem as this where queries never ended. I split it up in an attempt
to
solve that
Hi,
On Sat, 04 Jan 2014 16:23:42 +0100, Andrew Sullivan
wrote:
On Sat, Jan 04, 2014 at 12:14:42PM +0100, Yngve N. Pettersen wrote:
The update query looks like this:
UPDATE queue SET state = E'S' WHERE state = E'I' AND id IN () RETURNING id;
There is a BEGIN/CO
Hello all,
I am running a Postgresql 9.2 system (IIRC v9.2.4; I am about to upgrade
to 9.2.6) on a system with 32-cores, 256GB RAM, 64GB shared RAM for
postgresql. The applications I am running are written using Django
(currently v1.5)
For a while I have been observing what may be special
IN (SELECT random_id_sample())
FOR UPDATE
--
Sincerely,
Yngve N. Pettersen
Senior Developer Email: yn...@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 23 69 32 60
improve the predictability of FOR
UPDATE's
interactions with LIMIT/OFFSET, and indeed it's improved the
predictability
of the behavior for you, just not in the direction you'd like :-(
regards, tom lane
--
Sincerely,
Yngve N. Pettersen
**
