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 <dev@archonet.com>)
Ответы Re: slow full table update  (Tomas Vondra <tv@fuzzy.cz>)
Список 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 по дате отправления:

Предыдущее
От: "Andrus"
Дата:
Сообщение: Re: Increasing select max(datecol) from bilkaib wheredatecol<=date'2008-11-01' and (cr='00' or db='00') speed
Следующее
От: "Scott Marlowe"
Дата:
Сообщение: Re: slow full table update