🛠️ Запросу нужен один день, но в плане остались все месячные партиции
Артефакт:
Append
-> Seq Scan on events_2026_01
-> Seq Scan on events_2026_02
-> Seq Scan on events_2026_03
...
-> Seq Scan on events_2026_12
Первая реакция — добавить индексы.
Но pruning и индекс решают разные задачи.
partition pruning отвечает:
Индекс отвечает:
Если лишние месяцы не исключены, индекс на каждой партиции не исправит причину.
Что проверить:
— ключ и способ партиционирования;
— границы дочерних таблиц;
— фактический WHERE;
— типы ключа и параметров;
— функции и cast над ключом;
— реальные значения параметров;
— enable_partition_pruning;
— сколько партиций осталось под Append;
— какие дочерние узлы реально выполнялись.
Append сам по себе не ошибка.
Варианты плана:
Append
-> Seq Scan on events_2026_08
Лишние партиции отсутствуют. Pruning мог пройти при планировании.
Под-планы могли быть исключены при инициализации.
Узел не запускался при выполнении. Но это нужно смотреть вместе со всем планом и loops.
Почему pruning мог не сработать:
— условие не ограничивает ключ партиционирования;
— ключ обёрнут в функцию, например date(event_time);
— тип параметра отличается от типа ключа;
— таблица разделена по выражению, а запрос использует другую форму;
— параметры становятся известны только при выполнении;
— условие действительно затрагивает несколько партиций.
Prepared statement с $1 и $2 не означает автоматического чтения всех партиций. PostgreSQL может исключать их позже — при инициализации или выполнении.
И не переписывайте условие по времени механически. Для timestamp, timestamptz и бизнес-дня важны типы и границы.
Типичная ошибка — лечить каждый дочерний Seq Scan отдельным индексом.
Вывод: сначала проверьте, почему партиции остались в плане. Потом анализируйте Seq Scan, Index Scan и индексы внутри оставшихся партиций.
Сохраните признаки, по которым в плане видно, что проблема начинается до выбора индекса — на этапе отбора партиций.
🔹🔹🔹🔹
Артефакт:
Append
-> Seq Scan on events_2026_01
-> Seq Scan on events_2026_02
-> Seq Scan on events_2026_03
...
-> Seq Scan on events_2026_12
Первая реакция — добавить индексы.
Но pruning и индекс решают разные задачи.
partition pruning отвечает:
какие партиции можно исключить?
Индекс отвечает:
как читать строки внутри оставшейся партиции?
Если лишние месяцы не исключены, индекс на каждой партиции не исправит причину.
Что проверить:
— ключ и способ партиционирования;
— границы дочерних таблиц;
— фактический WHERE;
— типы ключа и параметров;
— функции и cast над ключом;
— реальные значения параметров;
— enable_partition_pruning;
— сколько партиций осталось под Append;
— какие дочерние узлы реально выполнялись.
Append сам по себе не ошибка.
Варианты плана:
Append
-> Seq Scan on events_2026_08
Лишние партиции отсутствуют. Pruning мог пройти при планировании.
Subplans Removed: 11
Под-планы могли быть исключены при инициализации.
(never executed)
Узел не запускался при выполнении. Но это нужно смотреть вместе со всем планом и loops.
Почему pruning мог не сработать:
— условие не ограничивает ключ партиционирования;
— ключ обёрнут в функцию, например date(event_time);
— тип параметра отличается от типа ключа;
— таблица разделена по выражению, а запрос использует другую форму;
— параметры становятся известны только при выполнении;
— условие действительно затрагивает несколько партиций.
Prepared statement с $1 и $2 не означает автоматического чтения всех партиций. PostgreSQL может исключать их позже — при инициализации или выполнении.
И не переписывайте условие по времени механически. Для timestamp, timestamptz и бизнес-дня важны типы и границы.
Типичная ошибка — лечить каждый дочерний Seq Scan отдельным индексом.
Вывод: сначала проверьте, почему партиции остались в плане. Потом анализируйте Seq Scan, Index Scan и индексы внутри оставшихся партиций.
Сохраните признаки, по которым в плане видно, что проблема начинается до выбора индекса — на этапе отбора партиций.
🔹🔹🔹🔹