Re: BUG #4945: Parallel update(s) gone wild

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dan Boeriu" <dan(dot)boeriu(at)roost(dot)com>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>, "PostgreSQL bugs" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #4945: Parallel update(s) gone wild
Date: 2009-07-30 21:34:48
Message-ID: 4174.1248989688@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Dan Boeriu" <dan(dot)boeriu(at)roost(dot)com> writes:
> Attached is the reproducible test case - I was able to reproduce the problem on 32 and 64 bit 8.3.6 and 8.4.0 RedHat 5.3 kernel 2.6.18-128.1.16.el5 #1 SMP

I looked at this a bit. It's the same issue discussed at
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php
namely, that the second update finds itself trying to update a large
number of tuples that were already updated since its snapshot was taken.
That means it has to re-verify that the updated versions of those tuples
meet its WHERE qualification. That's done by a function EvalPlanQual
that's pretty darn inefficient for complex queries like this one.
It's essentially redoing the join (and recomputing the whole sub-SELECT)
for each row that needs to be updated.

Someday I'd like us to redesign that mechanism, but don't hold
your breath ...

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Dan Boeriu 2009-07-30 22:11:39 Re: BUG #4945: Parallel update(s) gone wild
Previous Message Pavel Stehule 2009-07-30 18:45:30 Re: fix: plpgsql: return query and dropped columns problem