> >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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster