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