Re: Hot standby and removing VACUUM FULL

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby and removing VACUUM FULL
Date: 2009-11-24 07:47:01
Message-ID: 1259048821.30357.35.camel@hvost1700
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2009-11-24 08:17:29 Re: Partitioning option for COPY
Previous Message Heikki Linnakangas 2009-11-24 07:33:04 Re: KNNGiST for knn-search