Под секционированием понимается разделение логически единой большой таблицы на физические сегменты меньшего размера. Секционирование может обеспечить ряд преимуществ:

Данные преимущества обычно оправданы только в тех случаях, когда без секционирования таблица имела бы очень большой размер. Момент, когда секционирование таблицы становится целесообразным, зависит от конкретного приложения, однако эмпирическое правило гласит, что размер таблицы должен превышать объем физической памяти сервера базы данных.

Digital Q.DataBase предлагает встроенную поддержку следующих форм секционирования:

Если в приложении необходимо использовать формы секционирования, не перечисленные выше, можно использовать альтернативные методы, такие как наследование и UNION ALL вместо этого можно использовать представления. Такие методы обеспечивают гибкость, но не обладают некоторыми преимуществами производительности, характерными для встроенного декларативного секционирования.

Digital Q.DataBase позволяет объявить, что таблица разделяется на секции. Таблица, которая разделяется, называется секционированная таблица. Объявление включает в себя метод секционирования как описано выше, а также список столбцов или выражений, используемых в качестве ключ секционирования.

Сама секционированная таблица является «виртуальной» таблицей, не имеющей собственного хранилища. Вместо этого хранилище принадлежит секции, которые в остальном являются обычными таблицами, связанными с секционированной таблицей. Каждая секция хранит подмножество данных, определяемое её границами секции. Все строки, вставляемые в секционированную таблицу, будут перенаправлены в соответствующую секцию на основе значений столбцов ключа секционирования. Обновление ключа секционирования строки приведет к её перемещению в другую секцию, если она больше не соответствует границам своей исходной секции.

Секции сами могут быть определены как секционированные таблицы, что приводит к подсекционированию. Хотя все секции должны содержать те же столбцы, что и их секционированный родительский элемент, они могут иметь собственные индексы, ограничения и значения по умолчанию, отличные от характеристик других секций. См. CREATE TABLE для получения подробной информации о создании секционированных таблиц и секций.

Обычную таблицу невозможно преобразовать в секционированную или наоборот. Однако можно добавить существующую обычную или секционированную таблицу в качестве секции к секционированной таблице или удалить секцию из секционированной таблицы, превратив её в отдельную таблицу; это позволяет упростить и ускорить многие процессы обслуживания. См. ALTER TABLE для получения дополнительных сведений о ATTACH PARTITION и DETACH PARTITION подкомандах.

Секции также могут быть сторонними таблицами, хотя это требует осторожности, так как в этом случае ответственность за соответствие содержимого сторонней таблицы правилу секционирования возлагается на пользователя. Существуют также и другие ограничения. См. CREATE FOREIGN TABLE для получения дополнительной информации.

CREATE TABLE measurement (
    city_id         int not null,
    logdate         тип DATE not null,
    peaktemp        int,
    unitsales       int
);

DROP TABLE measurement_y2006m02;

ALTER TABLE measurement DETACH PARTITION measurement_y2006m02;
ALTER TABLE measurement DETACH PARTITION measurement_y2006m02 CONCURRENTLY;

CREATE TABLE measurement_y2008m02 PARTITION OF measurement
    FOR VALUES FROM ('2008-02-01') TO ('2008-03-01')
    TABLESPACE fasttablespace;

CREATE TABLE measurement_y2008m02
  (LIKE measurement INCLUDING DEFAULTS INCLUDING CONSTRAINTS)
  TABLESPACE fasttablespace;

ALTER TABLE measurement_y2008m02 ADD CONSTRAINT y2008m02
   CHECK ( logdate >= DATE '2008-02-01' AND logdate < DATE '2008-03-01' );

\copy measurement_y2008m02 from 'measurement_y2008m02'
-- possibly some other data preparation work

ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
    FOR VALUES FROM ('2008-02-01') TO ('2008-03-01' );

CREATE INDEX measurement_usls_idx ON ONLY measurement (unitsales);

CREATE INDEX CONCURRENTLY measurement_usls_200602_idx
    ON measurement_y2006m02 (unitsales);
ALTER INDEX measurement_usls_idx
    ATTACH PARTITION measurement_usls_200602_idx;
...

ALTER TABLE ONLY measurement ADD UNIQUE (city_id, logdate);

ALTER TABLE measurement_y2006m02 ADD UNIQUE (city_id, logdate);
ALTER INDEX measurement_city_id_logdate_key
    ATTACH PARTITION measurement_y2006m02_city_id_logdate_key;
...

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

DROP TABLE measurement_y2006m02;

ALTER TABLE measurement_y2006m02 NO INHERIT measurement;

CREATE TABLE measurement_y2008m02 (
    CHECK ( logdate >= DATE '2008-02-01' AND logdate < DATE '2008-03-01' )
) INHERITS (measurement);

CREATE TABLE measurement_y2008m02
  (LIKE measurement INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
ALTER TABLE measurement_y2008m02 ADD CONSTRAINT y2008m02
   CHECK ( logdate >= DATE '2008-02-01' AND logdate < DATE '2008-03-01' );
\copy measurement_y2008m02 from 'measurement_y2008m02'
-- possibly some other data preparation work
ALTER TABLE measurement_y2008m02 INHERIT measurement;

Исключение секций — это метод оптимизации запросов, который повышает производительность для декларативно секционированных таблиц. Например:

SET enable_partition_pruning = on;                 -- по умолчанию
SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';

Без исключения секций вышеуказанный запрос сканировал бы каждую из секций measurement таблицей. При включенном исключении секций планировщик проанализирует определение каждой секции и докажет, что секцию не требуется сканировать, так как она не может содержать строк, соответствующих WHERE clause. Когда планировщик может это доказать, он исключает (отсекает) секцию из плана запроса.

С помощью команды EXPLAIN и enable_partition_pruning параметра конфигурации можно показать различие между планом, в котором было выполнено отсечение секций, и тем, в котором оно не производилось. Типичный неоптимизированный план для такой структуры таблиц:

SET enable_partition_pruning = off;
EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
                                    ПЛАН ЗАПРОСА
-------------------------------------------------------------------​ ----------------
 Aggregate  (cost=188.76..188.77 rows=1 width=8)
   ->  Append  (cost=0.00..181.05 rows=3085 width=0)
         ->  Seq Scan on measurement_y2006m02  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate >= '2008-01-01'::date)
         ->  Seq Scan on measurement_y2006m03  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate >= '2008-01-01'::date)
...
         ->  Seq Scan on measurement_y2007m11  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate >= '2008-01-01'::date)
         ->  Seq Scan on measurement_y2007m12  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate >= '2008-01-01'::date)
         ->  Seq Scan on measurement_y2008m01  (cost=0.00..33.12 rows=617 width=0)
               Filter: (logdate >= '2008-01-01'::date)

В некоторых или во всех секциях может использоваться сканирование индекса вместо последовательного сканирования всей таблицы, но суть в том, что для выполнения этого запроса вообще нет необходимости сканировать старые секции. При включении исключения секций формируется значительно более эффективный план, который возвращает тот же результат:

SET enable_partition_pruning = on;
EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
                                    ПЛАН ЗАПРОСА
-------------------------------------------------------------------​ ----------------
 Aggregate  (cost=37.75..37.76 rows=1 width=8)
   ->  Seq Scan on measurement_y2008m01  (cost=0.00..33.12 rows=617 width=0)
         Filter: (logdate >= '2008-01-01'::date)

Следует отметить, что механизм исключения секций работает только на основе ограничений, неявно определяемых ключами секционирования, а не на основе наличия индексов. Таким образом, определять индексы для столбцов ключа не обязательно. Необходимость создания индекса для конкретной секции зависит от того, будут ли запросы при сканировании секции затрагивать большую или малую её часть. Индекс будет полезен во втором случае, но не в первом.

Исключение секций может выполняться не только во время планирования заданного запроса, но и во время его выполнения. Это полезно, так как позволяет исключить больше секций в тех случаях, когда условия содержат выражения, значения которых неизвестны на этапе планирования запроса, например, параметры, определенные в команде PREPARE , при использовании значения, полученного из подзапроса, или при использовании параметризованного значения на внутренней стороне соединения вложенным циклом. Исключение секций во время выполнения может производиться в любой из следующих моментов:

Исключение секций можно отключить с помощью enable_partition_pruning параметра.

Исключение ограничений — это метод оптимизации запросов, аналогичный механизму исключения секций. Хотя данный метод в основном используется для секционирования, реализованного с помощью устаревшего наследования, он может применяться и для других целей, в том числе при декларативном секционировании.

Исключение ограничений работает аналогично исключению секций, за исключением того, что в данном случае используются CHECK ограничения каждой таблицы — отсюда и название метода — тогда как при исключении секций используются границы секций таблицы, которые существуют только в случае декларативного секционирования. Еще одно отличие состоит в том, что исключение ограничений применяется только на этапе планирования; на этапе выполнения попытки исключения секций не производятся.

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

Значение по умолчанию (и рекомендуемое) для constraint_exclusion не является ни on ни off, а представляет собой промежуточную настройку под названием секция, при которой этот метод применяется только к запросам, работающим с таблицами, секционированными через наследование. Настройка on заставляет планировщик проверять CHECK ограничения во всех запросах, даже в простых, где это вряд ли принесет пользу.

В отношении механизма исключения ограничений действуют следующие предостережения:

Выбор способа секционирования таблицы следует производить тщательно, так как неудачное проектирование может отрицательно сказаться на производительности планирования и выполнения запросов.

Одним из наиболее важных проектных решений является выбор столбца или столбцов, по которым будут секционироваться данные. Часто оптимальным выбором является секционирование по столбцу или набору столбцов, которые чаще всего встречаются в WHERE предложениях запросов, выполняемых к секционированной таблице. WHERE предложения, совместимые с ограничениями границ секций, могут быть использованы для исключения ненужных секций. Однако требования к PRIMARY KEY или UNIQUE ограничение. Необходимость удаления устаревших данных также является фактором, который следует учитывать при планировании стратегии секционирования. Отсоединение целой секции выполняется довольно быстро, поэтому целесообразно разработать стратегию секционирования таким образом, чтобы все данные, подлежащие одновременному удалению, находились в одной секции.

Выбор оптимального количества секций, на которые должна быть разделена таблица, также является критически важным решением. Недостаточное количество секций может привести к тому, что индексы останутся слишком большими, а локальность данных — низкой, что в свою очередь повлечет за собой низкий коэффициент попадания в кэш. Однако разделение таблицы на слишком большое количество секций также может создать определенные проблемы. Избыточное количество секций может привести к увеличению времени планирования запросов и повышенному потреблению памяти как при планировании, так и при выполнении запросов, что более подробно описано ниже. При выборе стратегии секционирования таблицы также важно учитывать возможные изменения в будущем. Например, если выбрана схема «одна секция на одного клиента» и на данный момент имеется небольшое число крупных клиентов, следует учитывать последствия ситуации, когда через несколько лет количество клиентов станет большим, а сами они — мелкими. В этом случае может быть целесообразнее выбрать секционирование по HASH и выбрать разумное количество секций вместо того, чтобы пытаться использовать секционирование по LIST и надеяться, что число клиентов не увеличится сверх того предела, при котором секционирование данных остается практичным.

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

Важно учитывать накладные расходы на секционирование в процессе планирования и выполнения запросов. Планировщик запросов, как правило, способен достаточно эффективно обрабатывать иерархии, включающие до нескольких тысяч секций, при условии, что типичные запросы позволяют планировщику выполнять исключение секций, оставляя лишь небольшое их число. Время планирования увеличивается, а потребление памяти растет, если после выполнения планировщиком исключения секций остается значительное количество секций. Еще одна причина для беспокойства при наличии большого количества секций заключается в том, что потребление памяти сервером может значительно расти со временем, особенно если множество сессий обращаются к большому количеству секций. Это связано с тем, что каждая секция требует загрузки своих метаданных в локальную память каждой сессии, которая с ней взаимодействует.

При рабочих нагрузках типа хранилищ данных может быть целесообразно использовать большее количество секций, чем при OLTP -типе нагрузки. Как правило, в хранилищах данных время планирования запросов имеет меньшее значение, так как большая часть времени обработки затрачивается на выполнение запроса. Для обоих этих типов нагрузки важно принять правильные решения на ранних этапах, так как повторное секционирование больших объемов данных может выполняться крайне медленно. Моделирование предполагаемой нагрузки часто оказывается полезным для оптимизации стратегии секционирования. Никогда не следует исходить из предположения, что большее количество секций всегда лучше, чем меньшее, или наоборот.