Re: Cleaning up large objects

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Cleaning up large objects
Дата
Msg-id 29794.1092160326@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Cleaning up large objects  ("Ole Streicher" <ole-usenet-spam@gmx.net>)
Список pgsql-jdbc
"Ole Streicher" <ole-usenet-spam@gmx.net> writes:
> What is wrong with my approach that it does not free the disk space?

Plain vacuum is not designed to "free" disk space, at least not in the
sense of returning it to the operating system.  What it's designed to do
is record free disk space within table files in the "free space map"
(FSM) so that it can be re-used for future row creation.

To aggressively compact table files and return space to the OS, you need
vacuum full, which is a great deal slower and requires exclusive table
locks.

If you see space leakage in a database that should have a reasonably
constant total size, the reason is usually that you don't have the FSM
parameters set large enough to remember all the free space.  Check your
settings in postgresql.conf and increase if needed.  (Note that an
increase requires a postmaster restart to take effect.)  You might also
want to think about vacuuming more often than once a day, so that space
can be recycled into the FSM sooner.  When you have a periodic bulk
delete process, it's not a bad idea to vacuum the table that had the
deletes immediately after each deletion run.

Depending on how far behind the eight-ball you are, you may need a pass
of vacuum full to get the DB back down to a reasonable size.

BTW, "cluster" can serve as a substitute for vacuum full, since it also
compacts out dead space.  It can be significantly faster than vacuum
full when there's a lot of space to be reclaimed.

            regards, tom lane

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

Предыдущее
От: Jorge Ivan Ortiz Amestelli
Дата:
Сообщение: Unsuscribe
Следующее
От: Kris Jurka
Дата:
Сообщение: Re: Cleaning up large objects