Re: Hot standby and removing VACUUM FULL
От | Hannu Krosing |
---|---|
Тема | Re: Hot standby and removing VACUUM FULL |
Дата | |
Msg-id | 1259048821.30357.35.camel@hvost1700 обсуждение исходный текст |
Ответ на | Re: Hot standby and removing VACUUM FULL (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | 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 >
В списке pgsql-hackers по дате отправления: