Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

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: Thu, 30 Jul 2009 17:34:48 -0400
  • Message-id: <4174.1248989688@sss.pgh.pa.us> <text/plain>

"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



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group