Re: Feedback on getting rid of VACUUM FULL
От | Andrew McNamara |
---|---|
Тема | Re: Feedback on getting rid of VACUUM FULL |
Дата | |
Msg-id | 20090917010901.DE6B65AC0D6@longblack.object-craft.com.au обсуждение исходный текст |
Ответ на | Re: Feedback on getting rid of VACUUM FULL (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
>Well, Andrew McNamara just posted today: >http://archives.postgresql.org/message-id/20090916063341.0735C5AC0D6@longblack.object-craft.com.au > >Had VACUUM FULL not been available, though, I'm pretty sure he would've >come up with something else instead. Indeed I would have. And it was our own slackness that got us into the situation. Several people suggested using a portable drive - in this case, it would not have been practical as the machines are physically managed by another group at a remote location (the paperwork would be the real blocker). Getting more drives added to the SAN would have been even more painful. >I was just going to post that we should make a decision about this, >because ISTM there's some code in Simon's hot standby patch that is only >required to support VACUUM FULL. If we make the decision that we drop >VACUUM FULL in 8.5, we can take that part out of the patch now. It's not >a huge amount of code, but still. > >I'm in favor of removing VACUUM FULL in 8.5. To replace it, we should offer: > >1) VACUUM REWRITE, which is like CLUSTER but doesn't use an index, and My preference would be to keep the VACUUM FULL command, but to reimplement it as a table rewriter (like CLUSTER?). I see little risk to changing the behaviour without changing the name - only experts are currently aware exactly what it actually does, and they are more likely to keep an eye out for changes like this. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
В списке pgsql-hackers по дате отправления: