Партиционирование
Тема дорожной карты · PostgreSQL
Секционирование таблиц в PostgreSQL делит большую таблицу на более мелкие физические подтаблицы — секции, каждая из которых хранит подмножество данных, определяемое стратегией секционирования: RANGE, LIST или HASH. PostgreSQL реализует секционирование декларативно: родительская таблица определяет ключ и стратегию секционирования, тогда как дочерние таблицы содержат фактические строки и могут иметь собственные индексы, пространства таблиц и параметры хранения, что является основой администрирования баз данных с большими наборами данных. Секционирование улучшает производительность запросов благодаря отсечению секций — планировщик пропускает нерелевантные секции — а также ускоряет массовую загрузку данных и упрощает управление жизненным циклом данных, например отсоединение и удаление старых секций вместо ресурсоёмких операций DELETE. Каждая секция является полностью независимой таблицей PostgreSQL, поэтому отдельные секции можно резервировать, восстанавливать или архивировать независимо. Понимание секционирования — ключевой навык настройки производительности при управлении таблицами с сотнями миллионов строк в продуктивных развёртываниях PostgreSQL.
Как это работает
Партиционирование разбивает одну логическую таблицу на много физических партиций: по range (timestamp), list (регионы) или hash (шардинг по id). Каждая партиция — реальная таблица; родительская — routing-слой. Constraint exclusion позволяет планировщику пропускать нерелевантные партиции. Postgres 10+ поддерживает декларативное (PARTITION BY RANGE); pg_partman автоматизирует создание и retention. Особенно полезно для time-series: DROP старых партиций (мгновенно) вместо DELETE (медленно + bloat).
Когда применять
Партиционируйте, когда одна таблица переваливает ~50-100M строк или начинает тянуть maintenance (VACUUM, REINDEX, запросы). Партиционируйте по колонке, по которой чаще всего фильтруете (обычно время). pg_partman — для time-based жизненного цикла. Не партиционируйте преждевременно — на < 10M строк это добавляет операционный overhead без пользы; хорошо настроенных индексов хватает.
Типичные ошибки
Ловушки Партиционирование: запросы без partition-ключа в WHERE (планировщик не может прунить — скан всех партиций, медленнее непартиционированного); unique constraint, обязанный охватить все партиции (нужен partition-ключ внутри); ручное создание партиций отстаёт (записи валятся, когда у "сегодня" нет партиции); over-партиционирование (10000 партиций по 100 строк — overhead планировщика затмевает выгоду).