Re: Autovacuum in the backend - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Autovacuum in the backend
Date
Msg-id Pine.LNX.4.58.0506161332490.19372@linuxworld.com.au
Whole thread Raw
In response to Re: Autovacuum in the backend  (Alvaro Herrera <alvherre@surnet.cl>)
Responses Re: Autovacuum in the backend
List pgsql-hackers
On Wed, 15 Jun 2005, Alvaro Herrera wrote:

> On Thu, Jun 16, 2005 at 11:07:31AM +1000, Gavin Sherry wrote:
> > On Wed, 15 Jun 2005, Bruce Momjian wrote:
> >
> > > I am going to start working on it.  I am concerned it is a big job.
> > >
> > > I will post questions as I find them, and the one below is a good one.
> >
> > I'm wondering if effort is being misdirected here. I remember when Mark
> > Wong at OSDL was running pg_autovacuum during a dbt run, he was seeing
> > significant performance loss -- I think on the order of 30% to 40% (I will
> > try and dig up a link to the results).
>
> I think those are orthogonal issues.  One is fixing whatever performance
> issues there are because of VACUUM.  Note that the fact that Mark was
> having such a drop in performance with autovacuum does only mean that
> at the enormous load under which the OSDL tests are run, autovacuum is
> not the best solution.  Not everybody runs with that sort of load
> anyway.  (In fact lots of people don't.)

I agree.

> So, one issue is that at high loads, there are improvements to be made
> to VACUUM.  The other issue is to get VACUUM to run in the first place,
> which is what autovacuum addresses.
>
> I can easily predict that we will make adjustments and improvements to
> VACUUM in the future, but I'm not so sure if it will happen before 8.1
> feature-freezes.  I have more confidence that we can integrate
> autovacuum for 8.1, which will be a leap forward.

I guess my main concern is that we'll have a solution to the problem of
dead tuples which is only half way there. It is only an incremental
improvement upon the contrib module and solves only one real problem:
users do not read up on VACUUM or autovacuum. This is at the expense of
making it appear to be suitable for the general user base when it isn't,
in my opinion. That isn't the fault of autovacuum but is a function of the
cost of ordinary vacuum.

Thanks,

Gavin


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Autovacuum in the backend
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Autovacuum in the backend