Pruning запросов
Тема дорожной карты · PostgreSQL
Отсечение секций — техника оптимизации запросов PostgreSQL, при которой планировщик исключает нерелевантные секции из плана выполнения запроса, значительно сокращая объём операций ввода-вывода и повышая производительность для больших секционированных таблиц. Когда оператор SELECT содержит условие WHERE по ключу секции, PostgreSQL определяет, какие секции могут содержать соответствующие строки, и сканирует только их, полностью пропуская остальные. Отсечение секций работает как для статического отсечения (вычисляемого при построении плана), так и для динамического (вычисляемого во время выполнения при использовании параметров или соединений), что обеспечивает его эффективность для широкого круга рабочих нагрузок при администрировании баз данных. Параметр конфигурации enable_partition_pruning управляет этим поведением, а вывод EXPLAIN показывает, какие секции включены в сканирование, а какие исключены. Правильное отсечение секций необходимо для достижения преимуществ производительности от секционирования в PostgreSQL, особенно в сценариях с временны́ми рядами и крупными аналитическими нагрузками.
Как это работает
Pruning запросов разбивает одну логическую таблицу на много физических партиций: по 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 без пользы; хорошо настроенных индексов хватает.
Типичные ошибки
Ловушки Pruning запросов: запросы без partition-ключа в WHERE (планировщик не может прунить — скан всех партиций, медленнее непартиционированного); unique constraint, обязанный охватить все партиции (нужен partition-ключ внутри); ручное создание партиций отстаёт (записи валятся, когда у "сегодня" нет партиции); over-партиционирование (10000 партиций по 100 строк — overhead планировщика затмевает выгоду).