Разбор от сообщества: Как сжатие данных в PostgreSQL влияет на производительность

1 октября 2026 · infolimp.ru

Контекст и ситуация

По следам обсуждения на Infostart (статья "Разбор от сообщества: Как сжатие данных в PostgreSQL влияет на производительность") очевидно: стандартная рекомендация «Включи pgzstd в конфиге и будет счастье» работает далеко не всегда. Под капотом PostgreSQL использует два механизма сжатия:

• TOAST (The Oversized-Attribute Storage Technique) — автоматическое сжатие значений, превышающих ~2 КБ. Работает на уровне строки, применяется по умолчанию (метод pglz).
• pgzstd — расширение, использующее алгоритм Zstandard. Часто рекомендуют как более эффективный по степени сжатия.
• Tuptle-level compression (страничное сжатие) — сжатие целых страниц данных. Требует настройки на уровне кластера.

Специалисты 1С с 5-15‑летним стажем, как правило, знают про TOAST, но редко учитывают стоимость распаковки при каждом доступе к полю. Именно здесь скрывается ловушка, превращающая ускорение в тормоз.

Технический разбор: не сжатие, а распаковка

Когда 1С читает реквизит документа или табличной части, содержимое которого превышает порог TOAST_TUPLE_THRESHOLD (по умолчанию ~2 КБ), PostgreSQL обязан:

1. Найти фрагмент в toast-таблице.
2. Распаковать его (если он упакован).
3. Собрать окончательное значение.

При каждом чтении такого поля — даже если данные не меняются — распаковка происходит заново. Это дополнительная нагрузка на CPU, которая легко может перекрыть выигрыш от уменьшенного I/O.

Особенно критично для:

• Отчётов, которые сканируют много строк с длинными комментариями (реквизиты типа «Строка(2000+)», «ХранилищеЗначения», табличные части с неограниченными строками).
• Сериализации/десериализации объектов (выгрузка в JSON, XML) — тут распаковка происходит на каждый элемент.
• Фоновых заданий, которые многократно обращаются к одним и тем же «толстым» данным.

Ситуация усугубляется при использовании pgzstd: степень сжатия выше → больше экономия диска, но и больше времени на распаковку (Zstandard быстрее pglz, но не бесплатен).

Нетривиальная ловушка: включили сжатие — упала производительность

Характерный сценарий из практики сообщества:

После включения pgzstd (через ALTER TABLE ... SET COMPRESSION) размер базы сократился на 25–40%. Но среднее время выполнения «Отчёта по продажам» выросло в 1,5–2 раза. Причина: в отчёте используется табличная часть с реквизитом «СодержаниеСобытия» (строка 5000 символов) — она сканируется полностью при каждом формировании. Раньше данные хранились без сжатия (I/O выше, но распаковка отсутствовала). После сжатия добавилась распаковка 2000 строк × 5 КБ — нагрузка на CPU возросла, и время запроса увеличилось.

Как это обнаружить? Используйте системные представления PostgreSQL:

SELECT relname, n_tup_dead, seq_scan, idx_scan, seq_tup_read
FROM pg_stat_user_tables 
WHERE relname = 'MyTable';

Резкий рост seq_tup_read при неизменном seq_scan — косвенный признак, что строки стали «тяжелее» для чтения (каждая требует распаковку). Прямой замер — профилирование запроса через EXPLAIN (ANALYZE, BUFFERS) и сравнение времени с отключенным сжатием.

Сравнение подходов: условия применимости

Ниже — сводка на основании наблюдений сообщества (не таблица, т.к. цифры сильно зависят от схемы данных):

• TOAST (pglz) по умолчанию: сбалансированный вариант. Рекомендуется почти всегда, если в базе есть крупные строки (документы, статьи, комментарии). Распаковка быстрее, чем Zstd, но степень хуже.
• pgzstd: максимальное сжатие. Полезен на серверах с избыточным CPU и дефицитом диска (SSD малого объёма). Опасен для OLAP-нагрузок, где много последовательных чтений больших полей. Лучше применять точечно — только для таблиц, которые редко читаются, но активно вставляются.
• Без сжатия (EXTERNAL STORAGE): для таблиц, где поля редко превышают 2 КБ, или где критична скорость чтения (например, таблицы-справочники с быстрым доступом по ссылке).

Золотого решения нет. Выбор метода должен опираться на профиль нагрузки: если 70% запросов — чтение, а поля с большими строками читаются редко, pgzstd выгоднее. Если данные многократно перечитываются — лучше оставить pglz или вообще отключить сжатие на конкретном поле.

Практическое руководство: что делать прямо сейчас

Чек-лист для настройки сжатия в базе 1С

1. Аудит «толстых» полей — через SQL запрос к pg_class и pg_attribute найдите таблицы и столбцы с attstorage = 'x' (compressed). Это те поля, которые сжимаются TOAST. Решите, нужно ли менять их режим.
2. Измерьте время I/O и CPU до и после включения сжатия. Используйте pg_stat_user_tables и EXPLAIN (ANALYZE) на ключевых отчётах.
3. Включайте pgzstd выборочно — не для всей базы, а для конкретных таблиц. Пример команды:
   ALTER TABLE "Document_Products" ALTER COLUMN "Comment" SET COMPRESSION pglz;
   (Заменить на zstd при наличии расширения)
4. Мониторьте нагрузку особенно на фоновые задания. Если после изменения время задания выросло — немедленно откатывайте.
5. Для таблиц с частыми UPDATE сжатие может снизить производительность из-за фрагментации toast-записей. Рассмотрите SET STORAGE PLAIN для полей, которые обновляются пометками удаления.

Типичные ошибки

• ❌ Включение pgzstd на всей базе «потому что статья советует». Без профилирования — гарантированный риск.
• ❌ Игнорирование TOAST-таблиц при оценке размера. Сжатие уменьшает основную таблицу, но toast-часть может вырасти.
• ❌ Использование ALTER TABLE ... SET COMPRESSION без перестройки таблицы (команда только меняет политику, а не пересжимает существующие данные). Нужен VACUUM FULL или CLUSTER.
• ❌ Предположение, что если в тестовой базе выигрыш есть, то в боевой будет так же. Зависит от объёма одновременных сессий и частоты чтения.

Статья подготовлена по материалам обсуждения на Infostart. Для глубокого изучения рекомендуем обратиться к исходной публикации, а также к документации PostgreSQL по управлению TOAST (раздел «TOAST — The Oversized-Attribute Storage Technique»).