Re: slow vacuum performance

From: pginfo <pginfo(at)t1(dot)unisoftbg(dot)com>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: slow vacuum performance
Date: 2004-03-24 17:08:51
Message-ID: 4061C0A3.6C0E1C10@t1.unisoftbg.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

scott.marlowe wrote:

> On Wed, 24 Mar 2004, pginfo wrote:
>
> > Hi,
> >
> > scott.marlowe wrote:
> >
> > > On Wed, 24 Mar 2004, pginfo wrote:
> > >
> > > > Hi,
> > > >
> > > > I am running pg 7.4.1 on linux box.
> > > > I have a midle size DB with many updates and after it I try to run
> > > > vacuum full analyze.
> > >
> > > Is there a reason to not use just regular vacuum / analyze (i.e. NOT
> > > full)?
> > >
> >
> > Yes, in case I make massive updates (only in my case of cource) for example
> > 2 M rows, I do not expect to have 2M new rows in next 180 days.That is the
> > reaso for running vacuum full.
> > My idea was to free unneedet space and so to have faster system.
> > It is possible that I am wrong.
>
> It's all about percentages. If you've got an average of 5% dead tuples
> with regular vacuuming, then full vacuums won't gain you much, if
> anything. If you've got 20 dead tuples for each live one, then a full
> vacuum is pretty much a necessity. The generally accepted best
> performance comes with 5 to 50% or so dead tuples. Keep in mind, having a
> few dead tuples is actually a good thing, as your database won't grow then
> srhink the file all the time, but keep it in a steady state size wise.

thanks for the good analyze,ivan.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2004-03-24 18:13:55 Re: slow vacuum performance
Previous Message Vivek Khera 2004-03-24 17:05:49 Re: [ADMIN] Benchmarking postgres on Solaris/Linux