Будет ли эффективно секционирование в СУБД PostgreSQL в случае, если принцип разбиения таблицы на секции и критерий выборки не совпадают?
Здравствуйте!
При работе с таблицей средних размеров (десятки млн. записей) выяснилось, что некоторые запросы выполняются достаточно долго. Для ускорения выборки решил включить секционирование в этой таблице. Но возникла следующая проблема. Дело в том, что критерий выборки записей из таблицы таков, что он не совпадает с принципом разбиения таблицы на секции. В качестве такого принципа было выбрано разбиение по первичному ключу, вся таблица была разделена на секции по 100 000 записей в каждой. Насколько я понимаю, толк от секционирования будет только в том случае, если упомянутые принцип разбиения и критерий выборки совпадают. Например, таблица разделена на секции, где каждая секция это один день, а в предложении WHERE у нас что-то вроде: "выбрать с даты такой-то по дату такую-то". Тогда СУБД в состоянии определить, к какой физической подтаблице нужно обратиться. В противном случае - нет, что и происходит в описанном мной случае - после включения секционирования скорость выборки не увеличилась. Поэтому, хотелось бы узнать, прав ли я в своих предположениях насчет секционирования и можно ли сделать его в указанном случае эффективным. В качестве СУБД используется Postgres Pro, секционирование включено с помощью плагина pg_pathman.
Спасибо!
Насколько я понимаю, толк от секционирования будет только в том случае, если упомянутые принцип разбиения и критерий выборки совпадают.
Абсолютно правильное понимание.
Одним из решений таких задач является введение избыточности: для ускорения выборки вы дублируете информацию в несколько таблиц и секционируете таблицу под конкретный запрос.
Либо вы проводите какую-то дополнительную агрегацию или уменьшение данных и храните в отдельной таблице. Опять же под запрос.
Либо вы делаете функцию партиционирования по нескольким полям, но это надо смотреть запросы. Будет работать только если фильтры запросов являются подмножествами друг друга
А с помощью explain analyze проверяли медленные запросы? Может быть, достаточно было бы просто создать нужные индексы - и запросы выполняться стали бы гораздо быстрее? Просто, насколько я знаю, секционирование обычно делают на гораздо больших объемах записей.