On Tue, 2009-11-24 at 09:24 +0200, Heikki Linnakangas wrote:
> Greg Smith wrote:
> > Heikki Linnakangas wrote:
> >> So I guess what I'm asking is: Does anyone see any show-stoppers in
> >> removing VACUUM FULL
> > Here's the disclaimers attached to the new VACUUM REPLACE implementation
> > from Itagaki:
> >
> > "We still need traditional VACUUM FULL behavior for system catalog
> > because we cannot change relfilenode for them. Also, VACUUM FULL REPLACE
> > is not always better than traditional VACUUM FULL; the new version
> > requires additional disk space and might be slower if we have a few dead
> > tuples."
> >
> > That first part seems like it would limit the ability to completely
> > discard the current behavior.
>
> For system catalog,s you could still use a utility like the one I
> experimented with at
> http://archives.postgresql.org/message-id/4AB15065.1000607@enterprisedb.com.
> Essentially, do a bunch of dummy UPDATEs on the rows that you want to
> move. It can cause serialization errors in concurrent updaters, like any
> UPDATE, but I think it would be good enough for the narrow remaining use
> case of shrinking system catalogs.
call it VACUUM SHRINK ;)
and you will need to do a REINDEX after using it to get full benefit,
same as ordinary VACUUM or VACUUM FULL.
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
