Re: Autovacuum in the backend

> >4) Related to this, I guess, is that a user's FSM settings might be
> >completely inappropriate. The 'Just read the manual' or 'Just read the
> >logs' argument doesn't cut it, because the main argument for autovacuum in
> >the backend is that people do not and will not.
> >  
> >
> 
> Agreed, it doesn't solve all problems, and I'm not arguing that the 
> integration of AV makes PostgreSQL newbie safe it just helps reduce the 
> newbie problem.   Again if the default FSM settings are inappropriate 
> for a database then the user is probably doing something more 
> complicated that a "my cat minka" database and will need to learn some 
> tuning skills anyway.
> 
> >5) It doesn't actually shrink tables -- ie, there's no VACUUM FULL. If
> >we're telling users about VACUUM less often than we are now, there's bound
> >to be bloating issues (see 4).
> >  
> >
> 
But what's stopping the implementation of a Partial VACUUM FULL, where we lock the table,
move enough blocks to shorten the relation so that there is say < 10% bloat, or whatever is
appropriate for that table.  Or even just short the table a few block, and repeat the process
when you have some time too.

> Not totally true, regular VACUUM can shrink tables a little (I think 
> only if there is free space at the end of the table it can cutoff 
> without moving data around).  But if AV is on and the settings are 
> reasonable, then a table shouldn't bloat much or at all.  Also, I don't 
> think we are telling people to VACUUM less, in fact tables that need it 
> will usually get VACUUM'd more, we are just telling the users that if 
> they turn AV on, they don't have to manage all the VACUUMing.

Regards

Russell Smith