Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

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

PG_TABLE_INDEX_BLOAT 1С:Предприятие и СУБД

Устранение разрастания таблиц и индексов в PostgreSQL: утилита pg_repack

Обновлено: 26.08.2026 · Официальная документация ↗
  • Таблица и ее индексы занимают сотни гигабайт на диске, хотя полезных данных в ней всего 10–20%.
  • Замедление сканирования индексов (Index Scan) из-за разреженности страниц в B-Tree структурах.
  • Невозможность выполнить VACUUM FULL из-за недопустимости монопольной блокировки таблицы в рабочее время 1С.

1. Установка расширения pg_repack

# Для Debian / Ubuntu (PostgreSQL 16)
apt-get install -y postgresql-16-repack

# Включение расширения внутри целевой базы
psql -d Enterprise1C -c "CREATE EXTENSION pg_repack;"

2. Анализ разрастания (Bloat) таблиц и индексов

-- Проверка примерного процента мертвых страниц в индексах
SELECT 
    schemaname, tablename, indexname,
    pg_size_pretty(pg_relation_size(indexrelid)) AS IndexSize
FROM pg_stat_user_indexes
ORDER BY pg_relation_size(indexrelid) DESC LIMIT 10;

3. Запуск онлайн-дефрагментации через консоль

# Репак конкретной таблицы и всех ее индексов на лету
pg_repack -h 127.0.0.1 -p 5432 -U postgres -d Enterprise1C --table public._accumrgtn12345

# Репак только индексов всей базы данных в 4 параллельных потока
pg_repack -h 127.0.0.1 -p 5432 -U postgres -d Enterprise1C --only-indexes -j 4

4. Требования и проверка свободного дискового пространства

Для работы pg_repack на диске должно быть свободно не менее 100–120% от текущего размера обрабатываемой таблицы, так как утилита создает временную теневую копию таблицы и переносит данные через триггер логов изменений.

💡 Практика специалистов: Перед запуском pg_repack на таблицах размером > 100 ГБ временно отключите или увеличьте statement_timeout, а также убедитесь, что в базе не запущены долгие транзакции, иначе утилита не сможет взять финальную блокировку для подмены файлов.

Частые вопросы (FAQ)

Как pg_repack выполняет перепаковку без длительной блокировки таблицы?

Он создает временную таблицу, копирует в нее существующие данные, параллельно собирает все новые входящие изменения (INSERT/UPDATE/DELETE) через триггер в таблицу журнала, накатывает их и в конце кратковременно берет блокировку AccessExclusiveLock на доли секунды только для подмены файлов в каталоге.

Обязательно ли наличие Primary Key или NOT NULL Unique индекса для pg_repack?

Да. Для перепаковки таблицы целиком pg_repack требует наличия первичного ключа (PRIMARY KEY) или уникального индекса с полями NOT NULL. Перепаковка только индексов (--only-indexes) работает без этого ограничения.

Что делать, если процесс pg_repack аварийно оборвался?

В базе могут остаться временные таблицы и триггеры в схеме repack. Удалите расширение DROP EXTENSION pg_repack CASCADE; и создайте его заново CREATE EXTENSION pg_repack;.

В чем отличие pg_repack от стандартной команды REINDEX CONCURRENTLY?

REINDEX CONCURRENTLY перестраивает только индексы без блокировок, но не может сжать и освободить место самого тела таблицы (Heap Bloat). pg_repack перестраивает как саму таблицу, так и все ее индексы.

Полезные материалы
Рекомендуем