pg_repack
pg_repack — единственный безопасный способ полностью убрать bloat в таблице или индексе на работающем prod без долгой блокировки. ide99 запускает pg_repack через UI с прогрессом и проверками безопасности.
Зачем нужно
После массовых UPDATE или DELETE Postgres-таблица обрастает «дырками» — старые версии строк (dead tuples). VACUUM помечает их свободными, но не возвращает диску. VACUUM FULL возвращает, но берёт AccessExclusiveLock — таблица блокируется полностью. На prod это часто неприемлемо.
pg_repack обходит проблему: он создаёт копию таблицы рядом, переливает данные, синхронизирует через триггер, и в самом конце атомарно подменяет — лок берётся на доли секунды.
Установка
CREATE EXTENSION pg_repack;
Расширение требует:
superuser для установки- Утилита командной строки
pg_repack на той же машине, где запускаете
- На managed-Postgres (Supabase, Neon, RDS) обычно недоступно — там используйте альтернативу: миграция на партиционированную таблицу через pg_partman.
Использование через ide99
- Откройте Health screen → секция Bloat.
- Найдите таблицу или индекс с высоким bloat (обычно > 30%).
- Кнопка Repack на строке.
Откроется визард:
- Target: таблица целиком, отдельный индекс, или несколько индексов
- Order by: можно при перепаковке отсортировать данные по ключу (cluster-эффект — связанные строки лежат рядом, кэш использует лучше)
- Jobs: степень параллелизма (default 1, можно увеличить если есть свободные CPU)
- Without dropping old: оставить старую копию для отката (если что-то пойдёт не так)
Превью команды:
pg_repack \
-h db.example.com -p 5432 -U postgres -d mydb \
--table public.events \
--order-by 'event_at DESC' \
--jobs 2
Кнопка Run repack запустит процесс. ide99 отобразит прогресс:
[1/4] Creating temp tables and triggers... ✓ 2s
[2/4] Copying tuples... 42% — 18M / 42M rows
[3/4] Creating indexes...
[4/4] Swapping tables...
Можно отменить — pg_repack аккуратно откатит свою временную таблицу.
Когда применять
| Ситуация |
Решение |
| Таблица < 10 GB, можно блокировать |
VACUUM FULL (проще и быстрее) |
| Таблица с активной записью на prod |
pg_repack |
| Часто только индекс распух |
REINDEX CONCURRENTLY (тоже без блокировки) |
| Данные постоянно растут, старые удаляются |
Партиционирование через pg_partman |
Требования
- Таблица должна иметь Primary Key или Unique Index (NOT NULL columns) — иначе
pg_repack не может отслеживать изменения через триггер.
- Свободного места на диске нужно ~× 2 от размера таблицы (создаётся копия).
ide99 проверяет оба условия перед запуском и предупредит, если что-то не так.
Совет: расписание
Не запускайте repack в час пик — даже без блокировки нагрузка на CPU и I/O вырастет. Хорошие окна:
- Ночные часы по основной аудитории
- Выходные
- После релиза, когда нагрузка обычно спадает
Что дальше