"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
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
pgsql-bugs by date
|Next:||From: Dan Boeriu||Date: 2009-07-30 22:11:39|
|Subject: Re: BUG #4945: Parallel update(s) gone wild |
|Previous:||From: Pavel Stehule||Date: 2009-07-30 18:45:30|
|Subject: Re: fix: plpgsql: return query and dropped columns problem|