Re: Hot standby and removing VACUUM FULL

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby and removing VACUUM FULL
Date: 2009-11-24 07:24:08
Message-ID: 4B0B8A18.1040604@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-11-24 07:33:04 Re: KNNGiST for knn-search
Previous Message Heikki Linnakangas 2009-11-24 07:19:59 Re: Hot standby and removing VACUUM FULL