Re: performance of insert/delete/update - Mailing list pgsql-performance

From scott.marlowe
Subject Re: performance of insert/delete/update
Date
Msg-id Pine.LNX.4.33.0211261142290.10813-100000@css120.ihs.com
Whole thread Raw
In response to Re: performance of insert/delete/update  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-performance
On Tue, 26 Nov 2002, Andrew Sullivan wrote:

> On Tue, Nov 26, 2002 at 11:06:47AM -0700, scott.marlowe wrote:
> > So, the difference in performance was around 4% slower.
> >
> > I'd hardly consider that a big hit against the database.
> >
> > Note that in every test I've made up and run, the difference is at most 5%
> > with vacuumdb -z running continuously in the background.  Big text fields,
> > lots of math, lots of fks, etc...
>
> Also, it's important to remember that you may see a considerable
> improvement in efficiency of some queries if you vacuum often, (it's
> partly dependent on the turnover in your database -- if it never
> changes, you don't need to vacuum often).  So a 5% hit in regular
> performance may be worth it over the long haul, if certain queries
> are way cheaper to run.  (That is, while you may get 4% slower
> performance overall, if the really slow queries are much faster, the
> fast queries running slower may well be worth it.  In my case,
> certainly, I think it is.)

Agreed.  We used to run vacuumdb at night only when we were running 7.1,
and we had a script top detect if it had hung or anything.  I.e. vacuuming
was still a semi-dangerous activity.  I now have it set to run every hour
(-z -a switches to vacuumdb).  I'd run it more often but we just don't
have enough load to warrant it.


pgsql-performance by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: performance of insert/delete/update
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Realtime VACUUM, was: performance of insert/delete/update