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

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

Tantor SE-1C предлагает встроенную поддержку следующих вариантов секционирования:

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

Tantor SE-1C позволяет объявить, что таблица разделена на секции. Таблица, которая разделена на секции, называется секционированной таблицей. Объявление состоит из метода разделения, описанного выше, а также списка столбцов или выражений, которые используются в качестве ключа разделения.

Сама секционированная таблица является “виртуальной” таблицей, не имеющей собственного хранилища. Хранилище используется секциям, которые являются обычными таблицами, связанными с секционированной таблицей. Каждая секция хранит подмножество данных, определенное границами секции. Все строки, вставленные в секционированную таблицу, будут направлены в соответствующую секцию на основе значений столбца(-ов) ключа разделения. Изменение ключа разделения строки приведет к перемещению ее в другую секцию, если она больше не удовлетворяет границам ее исходной секции.

Секции сами могут быть определены как секционированные таблицы, что приводит к разделению на подсекции. Хотя все секции должны иметь те же столбцы, что и их родительская секционированная таблица, секции могут иметь свои собственные индексы, ограничения и значения по умолчанию, отличные от других секций. См. 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;                 -- the default
SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';

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

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

SET enable_partition_pruning = off;
EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
                                    QUERY PLAN
-------------------------------------------------------------------​----------------
 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';
                                    QUERY PLAN
-------------------------------------------------------------------​----------------
 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, а является промежуточным значением, называемым partition, что приводит к применению его только к запросам, которые, вероятно, работают с унаследованными секционированными таблицами. Значение on заставляет планировщик проверять CHECK-ограничения во всех запросах, даже в простых, которые, вероятно, не принесут особой пользы.

Следующие пояснения относятся к исключению по ограничению:

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

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

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

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

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

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