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.
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 |
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) |