Re: VACUUM FULL memory requirements

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: VACUUM FULL memory requirements
Дата
Msg-id 4B265FD1020000250002D4A1@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: VACUUM FULL memory requirements  (Scott Marlowe <scott.marlowe@gmail.com>)
Ответы Re: VACUUM FULL memory requirements  (David Schnur <dnschnur@gmail.com>)
Список pgsql-admin
Scott Marlowe <scott.marlowe@gmail.com> wrote:

> My usage is dictated by using slony, which means I can't do the
> things I'd like, like just copying the data out of the table,
> truncating it, and copying it back in / renaming the newly created
> table as the old one etc.  So for me, and other slony users who
> can't do the wild westish stuff we'd otherwise resort to, vacuum
> full is very useful in some circumstances.  So, an improved vacuum
> full would be much appreciated.  The proposed replacement, would
> it still be able to recover lost space like the old one?

As I understand it (with some confidence that others will correct
any errors), the default behavior of VACUUM FULL in the new
arrangement will be to copy the table -- similar to CLUSTER but
without using an index.  The thing still up in the air is whether to
support the old style VACUUM FULL behavior as an INPLACE option.  In
any event, there will probably be a utility to move tuples from the
end of the table to free space, which will allow a normal VACUUM to
free the space to the OS.  This utility is proposed as a client app,
which you will need to schedule on your own as needed.

-Kevin

В списке pgsql-admin по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: VACUUM FULL memory requirements
Следующее
От: Evan Rempel
Дата:
Сообщение: Internal fragmentations statistics Was: VACUUM FULL memory requirements