Re: 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly over time - Mailing list pgsql-general

From Dann Corbit
Subject Re: 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly over time
Date
Msg-id D90A5A6C612A39408103E6ECDD77B829408D64@voyager.corporate.connx.com
Whole thread Raw
In response to 7.3.4 on Linux: UPDATE .. foo=foo+1 degrades massivly over time  (Philipp Buehler <pb-pgsql-g@mlsub.buehler.net>)
List 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 by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: [OT] Tom's/Marc's spam filters?
Next
From: Karsten Hilbert
Date:
Subject: Re: Unicode problem ???