To: Drew Wilson <drewmwilson@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: how to efficiently update tuple in many-to-many relationship? 
In-reply-to: <22512E5C-A60F-43E7-A370-257F7AF956FD@gmail.com> 
References: <233A9987-ABA5-4491-A304-FDA1F8FCD962@gmail.com>
	<14019.1176155022@sss.pgh.pa.us>
	<22512E5C-A60F-43E7-A370-257F7AF956FD@gmail.com>
Comments: In-reply-to Drew Wilson <drewmwilson@gmail.com>
	message dated "Mon, 09 Apr 2007 18:29:41 -0700"
Date: Mon, 09 Apr 2007 22:13:05 -0400
Message-ID: <16374.1176171185@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Drew Wilson <drewmwilson@gmail.com> writes:
> Here's the query plan for a SELECT statement that returns 1,207,161  
> rows in 6 seconds.
> ...
> And here's the query plan for the UPDATE query that seems to never  
> complete. (Execution time > 30 minutes.)

Well, the subplan is certainly the same as before, so it seems there are
two possibilities:

* there's something unreasonably inefficient about the hash join being
used to perform the IN (work_mem too small? inefficient-to-compare
datatype? bad data distribution?)

* the time is actually going into the UPDATE operation proper, or
perhaps some triggers it fires (have you got any foreign keys involving
this table?  what's checkpoint_segments set to?)

You could narrow it down by checking the runtime for
select count(*) from translation_pair_data
  where translation_pair_id in
        (select translation_pair_id from translation_pair_data ...

If that's slow it's the topmost hash join's fault, else we have
to look at the UPDATE's side effects.

			regards, tom lane