Re: Hot standby and removing VACUUM FULL
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Hot standby and removing VACUUM FULL |
| Дата | |
| Msg-id | 4B0B8A18.1040604@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Hot standby and removing VACUUM FULL (Greg Smith <greg@2ndquadrant.com>) |
| Ответы |
Re: Hot standby and removing VACUUM FULL
|
| Список | 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
В списке pgsql-hackers по дате отправления: