Re: 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly over time

Поиск
Список
Период
Сортировка
От Dann Corbit
Тема Re: 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly over time
Дата
Msg-id D90A5A6C612A39408103E6ECDD77B829408D64@voyager.corporate.connx.com
обсуждение исходный текст
Ответ на 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly over time  (Philipp Buehler <pb-pgsql-g@mlsub.buehler.net>)
Список pgsql-general
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Wednesday, April 21, 2004 12:19 PM
> To: Philipp Buehler
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] 7.3.4 on Linux: UPDATE .. foo=foo+1
> degrades massivly over time
>
>
> Philipp Buehler <pb-pgsql-g@mlsub.buehler.net> writes:
> > While running
> > UPDATE banner SET counterhalf=counterhalf+1 WHERE
> BannerID=50 several
> > thousand times, the return times degrade (somewhat linear).
>
> You need to vacuum occasionally ...
>
> > A following VACCUM brings back return times to 'start' -
> but I cannot
> > run VACUUM any other minute (?).
>
> Sure you can.

Look in contrib for pg_autovacuum
Build that project
Edit your Postgresql configuration and enable statistics
Restart your database server
After it settles down, start pg_autovacuum

BTW, you can build it for Win32 if you disable the fork() option for
logging purposes

This should be part of the server itself (along with the large object
cleanup).
IMO-YMMV.

See this article:
http://www.bricolage.cc/docs/Bric/DBA.html
And this one:
http://www.argudo.org/postgresql/soft-tuning.php


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

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: [OT] Tom's/Marc's spam filters?
Следующее
От: Karsten Hilbert
Дата:
Сообщение: Re: Unicode problem ???