горячую добавил поле;
ALTER TABLE history ADD COLUMN id SERIAL PRIMARY KEY;
БД выросла стала объёмом 7.3
После удалил созданное поле;
ALTER TABLE history DROP COLUMN id;
Размер БД упал до 5.76Gb
Не совсем понятно откуда такая разница. Ведь если логически размер должен стать как и прежде, при этом данные продолжают писаться в таблицу и деградация сервиса не наблюдается. История вроде так-же сохранилась.
Может кто что подсказать по данному факту?
а как именно размер смотрели? А то 300мб может быть много чем
select pg_database_size('zabbix');
Возможно поле которое вы дропнули было с тостами. Соответственно дропнулись связанные таблицы.
Связей не было, я создал поле и потом удалил его самостоятельно. Поле нужно было добавить для логической репликации.
Я не про те связи. Почитайте про toast в postgresql. Если поле больше 8кб то postgres создает еще одну скрытую таблицу, в которой нарезает данные порциями. При удалении поля из изначальной таблицы, toast таблица удаляется полностью.
Да, спасибо большое за наводку. Кратенько почитал, не знаком был с этой штукой. :( Вполне рабочая версия. Попробую погуглить, можно ли всё-же эти скрытые TOAST пощупать руками интересно? =)
Вот только для типа bigint (а именно колонка с типом bigint создаётся при ключевом слове SERIAL) -- toast не создаётся никогда.
Создание заполненной колонки переписывает таблицу полностью. Эффективно удаляя bloat и из таблицы и из индэксов. DROP COLUMN потом не удаляет данные из самой колонки -- а вот индэкс на ней да, удаляется полностью. Так что, вполне возможно, что реорганизацыи таблицы -- хватило, чтобы размер уменьшылся, несмотря на то, что в ней теперь лежыт на 8 байт на каждую строку большэ.
Понял, спасибо большое. Прочитал как раз про это в документации. Сейчас изучаю как это проверить на практике и поиграться образования для. Спасибо.
Обсуждают сегодня