Re: Bloated tables and why is vacuum full the only option

Поиск
Список
Период
Сортировка
От Sergey Konoplev
Тема Re: Bloated tables and why is vacuum full the only option
Дата
Msg-id CAL_0b1tsvhM77KkSzhY2BWrRZxyy8OxS1NRMK4H7Ae=DgaLurA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bloated tables and why is vacuum full the only option  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-performance
On Sun, Feb 9, 2014 at 2:58 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Sun, Feb 9, 2014 at 7:32 PM, Sergey Konoplev <gray.ru@gmail.com> wrote:
>> Try pgcompact, it was designed particularily for such cases like yours
>> https://github.com/grayhemp/pgtoolkit.
>
> It's a pity that that requires several sequential scans of the tables.
> For my case, that's probably as intrusive as the exclusive locks.

Probably you should run it with --no-pgstattuple if you are talking
about these seq scans. If your tables are not TOASTed then the
approximation method of gathering statistics would work pretty good
for you.

> I noticed I didn't mention, but the tables involved are around 20-50GB in size.

It is not the thing I would worry about. I regularly use it with even
bigger tables.

--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray.ru@gmail.com


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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Bloated tables and why is vacuum full the only option
Следующее
От: M Putz
Дата:
Сообщение: Strange performance boost with random()