Re: slow full table update - Mailing list pgsql-performance

From Tom Lane
Subject Re: slow full table update
Date
Msg-id 20663.1226523248@sss.pgh.pa.us
Whole thread Raw
In response to Re: slow full table update  (Richard Huxton <dev@archonet.com>)
Responses Re: slow full table update  (Tomas Vondra <tv@fuzzy.cz>)
List pgsql-performance
Richard Huxton <dev@archonet.com> writes:
> firerox@centrum.cz wrote:
>> I try explain query with this result
>> for 10.000 rows > update songs set views = 0 where sid > 20000 and sid < 30000
>>
>> Bitmap Heap Scan on songs  (cost=151.59..6814.29 rows=8931 width=526) (actual time=4.848..167.855 rows=8945 loops=1)

> This query says t is taking 167 milli-seconds, not 10 minutes as your
> first message said. Is this query actually slow?

The explain plan tree only shows the time to fetch/compute the new rows,
not to actually perform the update, update indexes, or fire triggers.
If there is a big discrepancy then the extra time must be going into
one of those steps.

8.1 does show trigger execution time separately, so the most obvious
problem (unindexed foreign key reference) seems to be excluded, unless
the OP just snipped that part of the output ...

            regards, tom lane

pgsql-performance by date:

Previous
From: "Andrus"
Date:
Subject: Re: Increasing select max(datecol) from bilkaib wheredatecol<=date'2008-11-01' and (cr='00' or db='00') speed
Next
From: "Scott Marlowe"
Date:
Subject: Re: slow full table update