Будет ли эффективно секционирование в СУБД PostgreSQL в случае, если принцип разбиения таблицы на секции и критерий выборки не совпадают?
===========================================================================================================================================

 Здравствуйте!  

При работе с таблицей средних размеров (десятки млн. записей) выяснилось, что некоторые запросы выполняются достаточно долго. Для ускорения выборки решил включить секционирование в этой таблице. Но возникла следующая проблема. Дело в том, что критерий выборки записей из таблицы таков, что он не совпадает с принципом разбиения таблицы на секции. В качестве такого принципа было выбрано разбиение по первичному ключу, вся таблица была разделена на секции по 100 000 записей в каждой. Насколько я понимаю, толк от секционирования будет только в том случае, если упомянутые принцип разбиения и критерий выборки совпадают. Например, таблица разделена на секции, где каждая секция это один день, а в предложении WHERE у нас что-то вроде: "выбрать с даты такой-то по дату такую-то". Тогда СУБД в состоянии определить, к какой физической подтаблице нужно обратиться. В противном случае - нет, что и происходит в описанном мной случае - после включения секционирования скорость выборки не увеличилась. Поэтому, хотелось бы узнать, прав ли я в своих предположениях насчет секционирования и можно ли сделать его в указанном случае эффективным. В качестве СУБД используется Postgres Pro, секционирование включено с помощью плагина pg\_pathman.  

Спасибо! 

> Насколько я понимаю, толк от секционирования будет только в том случае, если упомянутые принцип разбиения и критерий выборки совпадают.

   

Абсолютно правильное понимание.   

Одним из решений таких задач является введение избыточности: для ускорения выборки вы дублируете информацию в несколько таблиц и секционируете таблицу под конкретный запрос.  

Либо вы проводите какую-то дополнительную агрегацию или уменьшение данных и храните в отдельной таблице. Опять же под запрос.  

Либо вы делаете функцию партиционирования по нескольким полям, но это надо смотреть запросы. Будет работать только если фильтры запросов являются подмножествами друг друга 

 не будет. партиционируйте по датам, да так, чтобы каждый запрос не ходил более чем в одну партицию.  

индекса по дате должно хватить на таких объемах 

 А с помощью explain analyze проверяли медленные запросы? Может быть, достаточно было бы просто создать нужные индексы - и запросы выполняться стали бы гораздо быстрее? Просто, насколько я знаю, секционирование обычно делают на гораздо больших объемах записей.