🛠️ Запросу нужен один день, но в плане остались все месячные партиции
Артефакт:
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 и индексы внутри оставшихся партиций.
Сохраните признаки, по которым в плане видно, что проблема начинается до выбора индекса — на этапе отбора партиций.
🔹🔹🔹🔹
· 24.08
в проде с prepared statements есть подлянка: после ~5 выполнений постгрес переключается на generic plan, где $1 уже неизвестный тип, и pruning тихо отваливается. лечится либо plan_cache_mode = force_custom_plan, либо явным кастом параметра к типу ключа. без explain analyze именно на 6-м и далее вызове это не поймать, а в проде оно всплывает как «всё было ок, потом внезапно стало сканить все партиции»
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён