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