Re: slow full table update

From: Tom Lane
Subject: Re: slow full table update
Date: ,
Msg-id: 20663.1226523248@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: slow full table update  (Richard Huxton)
Responses: Re: slow full table update  (Tomas Vondra)
List: pgsql-performance

Tree view

slow full table update  (<>, )
 Re: slow full table update  (, )
  Re: slow full table update  (<>, )
   Re: slow full table update  (, )
    Re: slow full table update  (<>, )
     Re: slow full table update  (Richard Huxton, )
      Re: slow full table update  ("Vladimir Sitnikov", )
      Re: slow full table update  (Tom Lane, )
       Re: slow full table update  (Tomas Vondra, )
 Re: slow full table update  ("Scott Marlowe", )
  Re: slow full table update  (<>, )
   Re: slow full table update  ("Scott Marlowe", )
    Re: slow full table update  (Tomas Vondra, )
   Re: slow full table update  (PFC, )

Richard Huxton <> writes:
>  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:

From: "Scott Marlowe"
Date:
Subject: Re: Performance Question
From: "Dave Page"
Date:
Subject: Re: Performance Question