PostgreSQL, reindexdb

Стесняюсь спросить, а зачем тебе реиндекс? И ты делаешь выборочную индексацию или реиндекс тейбл/бд целиком?

/usr/lib/postgresql/9.6/bin/reindexdb -a -h localhost -p 5433 -U admin -w

На самом деле это инициатива нашего одинесного босса, первый год никто никто никаких реиндексаций не делал, и все работало, потом выяснилось, что реиндекс чота ускоряет.

В общем я заметил что реиндекс удаляет сильно устаревшие временные таблицы, которые остаются в результате некорректных завершений работы кластера. Это бывает очень очень редко, но ручками их грохать как то ломает, а шум от них забивает журнал.

В общем решил упростить жизнь адинесникам и зашедулить реиндекс.

Скажите, есть в моих действиях смысл? И не сочтите за труд как то расшифровать вал комментарий, можно не сейчас, задача не скрочная.

А на сколько большие БД?

Если уж, сказали так делать, то лучше замени на фул вакуум, запускается примерно так:

vacuumdb -a -f -v -z

Реиндекс тоже лочит, но вакуум фул физически убирает мертвые тюплы, после него - считай чистая и новая бд. Но нужно места x2 от того, что занимает база сейчас.

кластер более 100 гигов, но базы не большие, поменьше гига, но их соответственно более 100.

после него - считай чистая и новая бд

данные то на месте?

Но нужно места x2 от того, что занимает база сейчас.

я думал вакуум уменьшит размер на диске, а почему он увеличивает?

я думал вакуум уменьшит размер на диске, а почему он увеличивает?

Ну временно ж.

а то есть пока он работает с базой А, она распухает и потом возвращается к прежнему размеру, в то время как база Б остается в своем теле? То есть увеличения кластера в 2х не будет?

Не будет. Ты бы почитал, как работает VACUUM FULL, что ли, вот прямо по этим ключевым словам всё гуглится.

У тебя там автовакуум не включен? Ручками есть смысл запускать только когда данные большими порциями удаляешь. Причём если дропать данные партициями, ручками запускать смысла вообще нет.

P.S. Мнение DBA, не моё. Таблиц у нас было куда меньше, а данных куда больше.

Данные на месте.

Вакуум фул создает, по-сути, новые таблицы и файлы на диске, он как раз и освобождает используемое место, в отличии от обычного вакуума, который только освобождает тюплы для повторной записи.

Обьем и нужен двойной, если например таблица весит 100 гб, то он начнет рядом создавать еще одну такую же, но уже без свободных тюплов и она будет весить меньше, тут зависит на сколько большой блоат у тебя.

Ну и нормально настроить обычный автовакуум. У меня для борьбы и мониторинга блоата, целая экосистема на питоне написана)

Включен, при запуске сообщение есть

Тогда это всё мастурбация, имхо.

Замерь время выполнения десятка запросов до и то же самое после, да покажи главнюку. Сомневаюсь, что увидишь разницу.

Если у него там блоата 50%, то после фулвакума будет самое оно с замерами до и после. Тут еще вопрос как у него сам постгрес настроен

В общем, план такой:

1. Если влом следить за блоатом, ставишь в крон каждую неделю, в самое ненагруженное время фулл вакум, убедившись что с местом норм. У тебя ж есть мониторинг дисков, да?
2. Идешь к начу и говоришь ему, мол, чувак, у нас не MSSQL, где реиндекс норм тема, у нас постгрес и я сделал лучше, рассказываешь про регламентные на выходных по крону.
3. Забиваешь болт

Профит)

ну все, попробую на выходных, там время перед архивацией кластера есть, только надо будет замерить сколько full vacuum выполняется

/usr/lib/postgresql/9.6/bin/vacuumdb -h localhost -p 5433 -U admin -w -a -f -v -z

-8% к объему кластера, не сказать что много. Выполнялась менее 8 часов.

А какой объем базы, сколько баз, таблиц, индексов? А то просто так 8 часов не даёт информации.

178 гигов, 120 одинэсных баз, соответственно сколько там индексов…

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

А работать быстрее стало?)

неть