Re: Autovacuum in the backend

Поиск
Список
Период
Сортировка
От Russell Smith
Тема Re: Autovacuum in the backend
Дата
Msg-id 200506171856.17584.mr-russ@pws.com.au
обсуждение исходный текст
Ответ на Re: Autovacuum in the backend  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: Autovacuum in the backend  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список 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
changesthat 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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: Utility database (Was: RE: Autovacuum in the backend)
Следующее
От: Andreas Pflug
Дата:
Сообщение: Re: Utility database (Was: RE: Autovacuum in the backend)