From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Drew Wilson <drewmwilson(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: how to efficiently update tuple in many-to-many relationship? |
Date: | 2007-04-10 02:13:05 |
Message-ID: | 16374.1176171185@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Drew Wilson <drewmwilson(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Drew Wilson | 2007-04-10 05:46:29 | Re: how to efficiently update tuple in many-to-many relationship? |
Previous Message | Drew Wilson | 2007-04-10 01:29:41 | Re: how to efficiently update tuple in many-to-many relationship? |