Partitioning не ускоряет всё подряд: сначала проверьте, зачем он вообще нужен

Partitioning не ускоряет всё подряд: сначала проверьте, зачем он вообще нужен

Коллеги, давайте разберем план выполнения. Секционирование полезно, когда запросы почти всегда бьют в узкий диапазон: по дате, статусу, региону. Тогда planner может отсечь лишние куски таблицы и читать меньше данных. Если же фильтр размазан, а ключ секции не совпадает с реальным паттерном доступа, вы просто получите больше объектов, больше статистики и больше сюрпризов.

Типовые ошибки:
— секционируют по колонке, по которой почти не фильтруют;
— делают слишком мелкие секции и потом тонут в накладных расходах;
— ждут, что partitioning заменит индекс. Не заменит;
— забывают про нагрузку на вставки, VACUUM/аналогичные процедуры и бэкапы.

Посмотрим, что тут с I/O в реальности. Секционирование помогает, когда есть partition pruning: запрос читает не всю таблицу, а только нужные секции. Но если в условии есть функция над ключом, неявное приведение типов или OR по разным диапазонам, отсечение может сломаться. В итоге план красивый, а диски всё равно греются.

Отдельно проверьте обслуживание: отдельные секции проще архивировать, удалять и перестраивать, но сложнее поддерживать единообразную статистику и одинаковые индексы. Схема простая, но дьявол кроется в статистике.

Золотое правило: сначала мониторинг, потом индексы. А потом уже решайте, нужен ли partitioning. Иначе вместо ускорения вы получите дорогую организацию хранения с теми же медленными запросами.