Re: Autovacuum in the backend

From: Russell Smith <mr-russ(at)pws(dot)com(dot)au>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Alvaro Herrera <alvherre(at)surnet(dot)cl>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Autovacuum in the backend
Date: 2005-06-17 08:56:17
Message-ID: 200506171856.17584.mr-russ@pws.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> > The major reasons for autovacuum as I see it are as follows:
> >
> > * Reduces administrative overhead having to keep track of what tables
> > need to be vacuumed how often.
>
> Creates more overhead and thus reduces performance.
Or reduces vacuum overhead because the vacuum strategy is much better than
it was when you used cron. Especially as people get a chance to improve autovac.

> > * Reduces the total amount of time the system spends vacuuming since it
> > only vacuums when needed.
>
> Can be easily done with cron.
Can you do partial table vacuums with CRON?
You can work out the smartest time to vacuum with cron? I thought it just scheduled tasks at certain times.

>
> > * Keeps stats up-to-date automatically
>
> Which can be done with cron
An what is the management strategy for adjusting analyze when things change that you weren't aware of? (eg, big table changes that were unexpected)

>
> > * Eliminates newbie confusion
>
> RTFM

RTFM = MySQL in a lot of cases to be honest.

>
> > * Eliminates one of the criticisms that the public has against
> > PostgreSQL (justifed or not)
>
> Agreed.
This is really the same as the previous RTFM question/response. People criticise because vacuum is foreign to them,
and for newbie's that equals too hard, next db please. As much as it is a technical issue, it's an advocacy issue too.

Plus we finally get XID wraparound protection. We finally decided that for 8.1 we needed some protection, which I think
Tom committed. This again may be a newbie thing. But there are a lot of newbies out there then. We've see on the lists
and on IRC this problem pop up a number of times. And people say "Why didn't it tell me", RTFM it's exactly what they want
to hear, or the fact they thought they read the manual, and missed understanding that bit.

>
>
> Just so everyone knows from the get go here. I am purposely playing a
> little devils advocate. Autovacuum has some drawbacks. I think we should
> be **publicly** aware of them before we pursue integration.

It does have a number of issues. But I feel the integration issue is being addressed with a very short term view.
Once it's integrated there are a lot of patches, tweaks and changes that just can't be made until it is integrated.
The usefulness of some of the vacuum ideas that have been presented in the past will be able to become a reality.
The dead space map is a perfect example. People have talked about it for most of the time I've been around.
But until we have an integrated vacuum none of that can really happen.
>
> Heaven knows it would make my life easier if it was integrated but anyway...
>
I understand these are not nessecarily Josh's view, but I thought I would offer comments on them.

> Sincerely,
>
> Joshua D. Drake
>
Regards

Russell Smith
>
>
>
> >
> > Also, as VACUUM improves, autovacuum will improve with it.
> >
Or because of autovacuum, vacuum and autovacuum will improve.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Russell Smith 2005-06-17 09:01:15 Re: Autovacuum in the backend
Previous Message Andreas Pflug 2005-06-17 08:26:46 Re: Autovacuum in the backend

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2005-06-17 08:58:08 Re: Utility database (Was: RE: Autovacuum in the backend)
Previous Message Christopher Kings-Lynne 2005-06-17 08:47:03 Re: Utility database (Was: RE: Autovacuum in the backend)