Re: Performance degradation after successive UPDATE's

Поиск
Список
Период
Сортировка
От Bruno Wolff III
Тема Re: Performance degradation after successive UPDATE's
Дата
Msg-id 20051206204433.GA22168@wolff.to
обсуждение исходный текст
Ответ на Re: Performance degradation after successive UPDATE's  ("Assaf Yaari" <assafy@mobixell.com>)
Список pgsql-performance
On Tue, Dec 06, 2005 at 11:08:07 +0200,
  Assaf Yaari <assafy@mobixell.com> wrote:
> Thanks Bruno,
>
> Issuing VACUUM FULL seems not to have influence on the time.
That was just to get the table size back down to something reasonable.

> I've added to my script VACUUM ANALYZE every 100 UPDATE's and run the
> test again (on different record) and the time still increase.

Vacuuming every 100 updates should put an upperbound on how slow things
get. I doubt you need to analyze every 100 updates, but that doesn't
cost much more on top of a vacuum. However, if there is another transaction
open while you are doing the updates, that would prevent clearing out
the deleted rows, since they are potentially visible to it. This is something
you want to rule out.

> Any other ideas?

Do you have any triggers on this table? Are you updating any other tables
at the same time? In particular ones that are referred to by the problem table.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Russell Garrett
Дата:
Сообщение: Re: TSearch2 vs. Apache Lucene
Следующее
От: Bruno Wolff III
Дата:
Сообщение: Re: Can this query go faster???