Обновить

Комментарии 4

А вы чем сейчас перепаковываете раздутые таблицы — pg_repackVACUUM FULL в окно, pg_squeeze

pgcompacttable. Он требует меньше места

Лечение заболевшего гриппом примочками. Источник проблемы в проектировании структуры БД (не только для postgresql). Физической концентрации в одной таблице терабайтовых данных допускать нельзя в принципе. Часть данных, и/или по времени их возникновения, должны распределяться по нескольким таблицам. Также, в зависимости от задачи, в отдельные таблицы могут выноситься исторические данные агрегированные по дате/времени с удалением начальных данных из рабочих таблиц, но с сохранением их в отдельной архивной БД.

ну а что делать если случлиось ?

Вариантов на "что делать ?" может быть несколько. В том числе и как в данной статье. Нужно детально знать конкретику: какие в таблице данные, как часто поступают новые, как и какие по времени запрашиваются через select, есть ли в них агрегирование. Завязана ли таблица в запросах с другими таблицами, где они формируются: в разных местах (процедурах) непосредственно в самой СУБД или на клиентах тоже. Вопросов много, но без радикального физического разделения данных не обойтись. Что ж поделаешь, такова цена не качественного начального проектирования структуры БД.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации