Мозг, имеем Пг версии 11.5. Есть таблица на которой довольно

большая нагрузка. Оттуда удаляется колонка (колонка в запросах не используется). Размер базы распух в 2,5 раза где-то за пару минут (мы чуть не влетели в out of disk space), аварийно тормознули Пг, запустили заново размер базы вернулся в нормальное состояние.
Что это было? Почему так сильно распухла база? Что с этим делать?

Частично ответ я думаю что знаю: Пг, при удалении колонки на самом деле ее не удаляет, удаление происходит при SELECT'е судя по всему, но откуда в 2,5 раза-то? Тем более что база далеко не из одной этой таблицы состоит. Конкретные размеры базы и таблицы, если надо, приведу. Но все-таки вопросы остаются актуальными.

Ну он потер ссылку на столбец, а потом видимо начал вакуум делать, чтобы данные из таблицы рядом на диске лежали

Откуда 2,5 раза? (Для таблицы это не 2,5 это сильно больше)

Тут уже из логов надо анализировать. Если было чисто удаление столбца без запуска руками вакуума и прочего, так не могло случиться. А столбец индексируемый был? Может ещё и в составном индексе? Были ссылки на него? Вариантов много, так с лету наверно никто не скажет

Вакуум не запускали. В индексах его небыло.

Тогда логи только. Я в 170гб таблице удалял столбцы, проблем не было

Автовакум пошел

В htop смотрели?

Смотрели. И запросы которые 10мс по 4 секунды выполнялись и диск задрачивали по страшному.

по описанию похоже, что I/O был занят, значит можно предположить, что дефрагментация или типа того производилась

IO был забит Пг. дефрагментация на никсах - это что-то новенькое.

а причем тут Ось? Файловые системы подвержены фрагментации, может вы имели ввиду ssd/hard?

> Конкретные размеры базы и таблицы, если надо, приведу. Приведите (до и после, за счёт чего "размер базы распух в 2,5 раза"). Вы какую-то очень странную ситуацию описываете, на первый взгляд. > Пг, при удалении колонки на самом деле ее не удаляет На самом деле это metadata operation, т.е. она, по сути, почти ничего не делает и должна выполняться мгновенно (если ей удаётся получить lock) независимо от размера таблицы.

=> SELECT pg_size_pretty( pg_total_relation_size('...') ); pg_size_pretty ---------------- 13 GB (1 row) => SELECT pg_size_pretty( pg_database_size('...') ); pg_size_pretty ---------------- 159 GB (1 row) В момент перед тушением базы общий размер был около 400Гб

А это "до" или "после"? И из этого неясно, за счёт чего база росла...

Это после. До было примерно столько-же

> В момент перед тушением базы общий размер был около 400Гб Базы, полученный этим же запросом? А за счёт чего, не выявили (если нет — можно только гадать)?

Нет. Там мониторинг диска был. Сам запрос никто не думал тогда выполнять. Не до того было

Может, он просто врёт? ;) Это же самое простое объяснение, на самом деле...

Ну он сейчас показывает те-же объемы. И нет... Там IO дикое было и задержки запросов. То есть не врал.