On Monday 12 May 2014 10:10:36 David G Johnston wrote:
> Did you try rewriting the query to avoid using an IN expression?
>
> UPDATE foo SET processing = 't'
> FROM (
> SELECT id FROM foo WHERE processing = 'f' ORDER BY id ASC LIMIT 5000 FOR
> UPDATE
> ) src
> WHERE foo.id = src.id;
>
> The worka
On Friday 09 May 2014 08:36:04 David G Johnston wrote:
> This seems to likely be the same, still open, bug reported previously:
>
> No Number Assigned:
> http://www.postgresql.org/message-id/CANCipfpfzoYnOz5jj=UZ70_R=CwDHv36dqWSpw
> si27vpm1z...@mail.gmail.com
>
> #8464
> http://www.postgresql.or
Did you try rewriting the query to avoid using an IN expression?
UPDATE foo SET processing = 't'
FROM (
SELECT id FROM foo WHERE processing = 'f' ORDER BY id ASC LIMIT 5000 FOR
UPDATE
) src
WHERE foo.id = src.id;
The workaround I mentioned above said that a CTE was needed but I'm thinking
that a
On Friday 09 May 2014 16:53:49 Adrian Klaver wrote:
> On 05/09/2014 08:04 AM, Vincent de Phily wrote:
> > Thanks to all for taking an interest so far, this bug is... weird.
>
> Yes weird. I tried to replicate your query to see if I could see
> anything similar. Tried it on 9.0.17 and 9.3.4 and cou
On 05/09/2014 08:36 AM, David G Johnston wrote:
Vincent de Phily wrote
On Friday 09 May 2014 06:52:33 Adrian Klaver wrote:
On 05/09/2014 05:36 AM, Vincent de Phily wrote:
On Friday 09 May 2014 07:01:32 Tom Lane wrote:
Vincent de Phily <
vincent.dephily@
> writes:
In case it changes any
On 05/09/2014 08:04 AM, Vincent de Phily wrote:
On Friday 09 May 2014 06:52:33 Adrian Klaver wrote:
Thanks to all for taking an interest so far, this bug is... weird.
Yes weird. I tried to replicate your query to see if I could see
anything similar. Tried it on 9.0.17 and 9.3.4 and could
On 05/09/2014 08:14 AM, Vincent de Phily wrote:
On Friday 09 May 2014 08:01:47 Adrian Klaver wrote:
On 05/09/2014 01:45 AM, Vincent de Phily wrote:
Before you grow suspicious of that conf_getint, the config is loaded once
at program startup, and the overlarge results hapen together with normal
Vincent de Phily wrote
> On Friday 09 May 2014 06:52:33 Adrian Klaver wrote:
>> On 05/09/2014 05:36 AM, Vincent de Phily wrote:
>> > On Friday 09 May 2014 07:01:32 Tom Lane wrote:
>> >> Vincent de Phily <
> vincent.dephily@
> > writes:
>> >>> In case it changes anything, this is the uncut (but st
On Friday 09 May 2014 08:01:47 Adrian Klaver wrote:
> On 05/09/2014 01:45 AM, Vincent de Phily wrote:
> > Before you grow suspicious of that conf_getint, the config is loaded once
> > at program startup, and the overlarge results hapen together with normal
> > results without having left the loop.
On 05/09/2014 01:45 AM, Vincent de Phily wrote:
On Thursday 08 May 2014 16:56:25 Adrian Klaver wrote:
On 05/08/2014 03:11 PM, Vincent de Phily wrote:
On Thursday 08 May 2014 06:30:39 Adrian Klaver wrote:
On 05/08/2014 04:09 AM, Vincent de Phily wrote:
Before you grow suspicious of that con
On Friday 09 May 2014 07:01:32 Tom Lane wrote:
> Vincent de Phily writes:
> > In case it changes anything, this is the uncut (but still anonimized)
> >
> > function:
> > query = """UPDATE foo SET processing = 't' WHERE id IN
> >
> >(SELECT id FROM foo WHERE processing = 'f' O
Vincent de Phily writes:
> In case it changes anything, this is the uncut (but still anonimized)
> function:
> query = """UPDATE foo SET processing = 't' WHERE id IN
>
>
On Thursday 08 May 2014 16:56:25 Adrian Klaver wrote:
> On 05/08/2014 03:11 PM, Vincent de Phily wrote:
> > On Thursday 08 May 2014 06:30:39 Adrian Klaver wrote:
> >> On 05/08/2014 04:09 AM, Vincent de Phily wrote:
> > The histogram shows a large amount of small values, progressively becoming
> > r
On Thursday 08 May 2014 16:05:59 Sim Zacks wrote:
> On 05/08/2014 02:09 PM, Vincent de Phily wrote:
> The problem is that sometimes (once every few days at about 2-300K queries
> per day) I get many more rows than the max 5000 I asked for (I've seen up
> to 25k). And I'm getting timeouts and other
On 05/08/2014 03:11 PM, Vincent de Phily wrote:
On Thursday 08 May 2014 06:30:39 Adrian Klaver wrote:
On 05/08/2014 04:09 AM, Vincent de Phily wrote:
Hello,
DO_LOOP is tested in a few places where we can make a clean exit. A cronjob
will restart the process if it is not or badly running.
On Thursday 08 May 2014 06:30:39 Adrian Klaver wrote:
> On 05/08/2014 04:09 AM, Vincent de Phily wrote:
> > Hello,
> >
> > I'm processing records in batches using PG 9.1.12, python 2.7, and psycopg
>
> > 2.5.2 :
> Comments in the code below:
> > def enqueue_loop(q):
> > curs = DB_HANDLER.cur
On 05/08/2014 04:09 AM, Vincent de Phily wrote:
Hello,
I'm processing records in batches using PG 9.1.12, python 2.7, and psycopg
2.5.2 :
Comments in the code below:
def enqueue_loop(q):
curs = DB_HANDLER.cursor()
query = """UPDATE foo SET processing = 't' WHERE id IN
On 05/08/2014 02:09 PM, Vincent de
Phily wrote:
The problem is that sometimes (once every few days at about 2-300K queries per
day) I get many more rows than the max 5000 I asked for (I've seen up to 25k).
And I'm getting timeouts and other problems as a result.
Hello,
I'm processing records in batches using PG 9.1.12, python 2.7, and psycopg
2.5.2 :
def enqueue_loop(q):
curs = DB_HANDLER.cursor()
query = """UPDATE foo SET processing = 't' WHERE id IN
19 matches
Mail list logo
