Re: slow full table update

От: Tom Lane
Тема: Re: slow full table update
Дата: ,
Msg-id: 20663.1226523248@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: slow full table update  (Richard Huxton)
Ответы: Re: slow full table update  (Tomas Vondra)
Список: pgsql-performance

Скрыть дерево обсуждения

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 по дате сообщения:

От: "Scott Marlowe"
Дата:
Сообщение: Re: Performance Question
От: "Dave Page"
Дата:
Сообщение: Re: Performance Question