Subject: Re: Slow update with simple query
From: Mark Lewis <mark.lewis@mir3.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Arnaud Lesauvage <thewild@freesurf.fr>, Ragnar <gnari@hive.is>,
	Jens Schipkowski <jens.schipkowski@apus.co.at>,
	pgsql-performance@postgresql.org
In-Reply-To: <8399.1166028385@sss.pgh.pa.us>
References: <457FDB1E.6040801@freesurf.fr>
	<op.tkhy4jpg81rjf6@xjens.apus.local> <457FF0CD.4050606@freesurf.fr>
	<op.tkh10qgw81rjf6@xjens.apus.local> <4580025D.2040903@freesurf.fr>
	<1166021340.6369.103.camel@localhost.localdomain>
	<45801A1B.6070200@freesurf.fr>  <8399.1166028385@sss.pgh.pa.us>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: MIR3, Inc.
Date: Wed, 13 Dec 2006 09:51:13 -0800
Message-Id: <1166032273.27428.98.camel@archimedes>
Mime-Version: 1.0

But he's using 8.1.4-- in that version, an explain analyze would list
the time taken to go through triggers, so the fact that we don't see any
of those lines means that it can't be constraint checking, so wouldn't
it have to be the index update overhead?

-- Mark

On Wed, 2006-12-13 at 11:46 -0500, Tom Lane wrote:
> Arnaud Lesauvage <thewild@freesurf.fr> writes:
> > Indeed, the new query does not perform that well :
> 
> > "Hash Join  (cost=112.75..307504.97 rows=2024869 width=355) (actual time=53.995..246443.811 rows=2020061 loops=1)"
> > ...
> > "Total runtime: 2777844.892 ms"
> 
> > I removed all unnecessary indexes on t1 before running the query (I left the index on uid and the multicolumn index containind the updated field).
> > I believe the multicolumn-functional-index computation is taking some time here, isn't it ?
> 
> Given that the plan itself only takes 246 sec, there's *something*
> associated with row insertion that's eating the other 2500+ seconds.
> Either index entry computation or constraint checking ...
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org