表分区
============

PostgreSQL支持基本的表划分。本小节介绍为何以及怎样把划分实现为数据库设计的一部分。

概述
--------------

划分指的是将逻辑上的一个大表分成一些小的物理上的片。划分有很多益处：

.. container:: itemizedlist

   -  在某些情况下查询性能能够显著提升，特别是当那些访问压力大的行在一个分区或者少数几个分区时。划分可以取代索引的主导列、减小索引尺寸以及使索引中访问压力大的部分更有可能被放在内存中。

   -  当查询或更新访问一个分区的大部分行时，可以通过该分区上的一个顺序扫描来取代分散到整个表上的索引和随机访问，这样可以改善性能。

   -  如果批量操作的需求是在分区设计时就规划好的，则批量装载和删除可以通过增加或者去除分区来完成。执行\ ``ALTER TABLE DETACH PARTITION``\ 或者使用\ ``DROP TABLE``\ 删除一个分区远快于批量操作。这些命令也完全避免了批量\ ``DELETE``\ 导致的\ ``VACUUM``\ 开销。

   -  很少使用的数据可以被迁移到便宜且较慢的存储介质上。

当一个表非常大时，划分所带来的好处是非常值得的。一个表何种情况下会从划分获益取决于应用，一个经验法则是当表的尺寸超过了数据库服务器物理内存时，划分会为表带来好处。

PostgreSQL对下列分区形式提供了内建支持：

.. container:: variablelist

   范围划分
      表被根据一个关键列或一组列划分为“范围”，不同的分区的范围之间没有重叠。例如，我们可以根据日期范围划分，或者根据特定业务对象的标识符划分。

   列表划分
      通过显式地列出每一个分区中出现的键值来划分表。

   哈希分区
      通过为每个分区指定模数和余数来对表进行分区。每个分区所持有的行都满足：分区键的值除以为其指定的模数将产生为其指定的余数。

如果你的应用需要使用上面所列之外的分区形式，可以使用诸如继承和\ ``UNION ALL``\ 视图之类的替代方法。这些方法很灵活，但是却缺少内建声明式分区的一些性能优势。

声明式划分
--------------

PostgreSQL提供了一种方法指定如何把一个表划分成称为分区的片段。被划分的表被称作\ *分区表*\ 。这种说明由\ *分区方法*\ 以及要被用作\ *分区键*\ 的列或者表达式列表组成。

所有被插入到分区表的行将被基于分区键的值路由到\ *分区*\ 中。每个分区都有一个由其\ *分区边界*\ 定义的数据子集。当前支持的分区方法是范围、列表以及哈希。

分区本身也可能被定义为分区表，这种用法被称为\ *子分区*\ 。分区可以有自己的与其他分区不同的索引、约束以及默认值。创建分区表及分区的更多细节请见\ `CREATE
TABLE <sql-createtable.html>`__\ 。

无法把一个常规表转换成分区表，反之亦然。不过，可以把一个包含数据的常规表或者分区表作为分区加入到另一个分区表，或者从分区表中移走一个分区并且把它变成一个独立的表。有关\ ``ATTACH PARTITION``\ 和\ ``DETACH PARTITION``\ 子命令的内容请见\ `ALTER
TABLE <sql-altertable.html>`__\ 。

个体分区在内部以继承的方式链接到分区表，不过无法对声明式分区表或其分区使用继承的某些一般特性（下文讨论）。例如，分区不能有除其所属分区表之外的父表，一个常规表也不能从分区表继承使得后者成为其父表。这意味着分区表及其分区不会参与到与常规表的继承关系中。由于分区表及其分区组成的分区层次仍然是一种继承层次，所有\ `第 5.10 节 <ddl-inherit.html>`__\ 中所述的继承的普通规则也适用，不过有一些例外，尤其是：

.. container:: itemizedlist

   -  分区表的\ ``CHECK``\ 约束和\ ``NOT NULL``\ 约束总是会被其所有的分区所继承。不允许在分区表上创建标记为\ ``NO INHERIT``\ 的\ ``CHECK``\ 约束。

   -  只要分区表中不存在分区，则支持使用\ ``ONLY``\ 仅在分区表上增加或者删除约束。一旦分区存在，那样做就会导致错误，因为当分区存在时是不支持仅在分区表上增加或删除约束的。不过，分区表本身上的约束可以被增加（如果它们不出现在父表中）和删除。

   -  由于分区表并不直接拥有任何数据，尝试在分区表上使用\ ``TRUNCATE``
      ``ONLY``\ 将总是返回错误。

   -  分区不能有在父表中不存在的列。在使用\ ``CREATE TABLE``\ 创建分区时不能指定列，在事后使用\ ``ALTER TABLE``\ 时也不能为分区增加列。只有当表的列正好匹配父表时，才能使用\ ``ALTER TABLE ... ATTACH PARTITION``\ 将它作为分区加入。

   -  如果\ ``NOT NULL``\ 约束在父表中存在，那么就不能删除分区的列上的对应的\ ``NOT NULL``\ 约束。

分区也可以是外部表，不过它们有一些普通表没有的限制，详情请见\ `CREATE
FOREIGN TABLE <sql-createforeigntable.html>`__\ 。

更新行的分区键可能导致它满足另一个不同的分区的分区边界，进而被移动到那个分区中。

声明式划分
++++++++++++++

假定我们正在为一个大型的冰激凌公司构建数据库。该公司每天测量最高温度以及每个区域的冰激凌销售情况。概念上，我们想要一个这样的表：

.. code:: programlisting

   CREATE TABLE measurement (
         city_id         int not null,
         logdate         date not null,
         peaktemp        int,
         unitsales       int
   );

我们知道大部分查询只会访问上周的、上月的或者上季度的数据，因为这个表的主要用途是为管理层准备在线报告。为了减少需要被存放的旧数据量，我们决定只保留最近3年的数据。在每个月的开始我们将去除掉最早的那个月的数据。在这种情况下我们可以使用分区技术来帮助我们满足对measurement表的所有不同需求。

要在这种情况下使用声明式分区，可采用下面的步骤：

.. container:: orderedlist

   1. 通过指定\ ``PARTITION BY``\ 子句把\ ``measurement``\ 表创建为分区表，该子句包括分区方法（这个例子中是\ ``RANGE``\ ）以及用作分区键的列列表。

      .. code:: programlisting

         CREATE TABLE measurement (
               city_id         int not null,
               logdate         date not null,
               peaktemp        int,
               unitsales       int
         ) PARTITION BY RANGE (logdate);

      你可能需要决定在分区键中使用多列进行范围分区。当然，这通常会导致较大数量的分区，其中每一个个体都比较小。另一方面，使用较少的列可能会导致粗粒度的分区策略得到较少数量的分区。如果条件涉及这些列中的一部分或者全部，访问分区表的查询将不得不扫描较少的分区。例如，考虑一个使用列\ ``lastname``\ 和\ ``firstname``\ （按照这样的顺序）作为分区键进行范围分区的表。

   2. 创建分区。每个分区的定义必须指定对应于父表的分区方法和分区键的边界。注意，如果指定的边界使得新分区的值会与已有分区中的值重叠，则会导致错误。向父表中插入无法映射到任何现有分区的数据将会导致错误，这种情况下应该手工增加一个合适的分区。

      分区以普通PostgreSQL表（或者可能是外部表）的方式创建。可以为每个分区单独指定表空间和存储参数。

      没有必要创建表约束来描述分区的分区边界条件。相反，只要需要引用分区约束时，分区约束会自动地隐式地从分区边界说明中生成。

      .. code:: programlisting

         CREATE TABLE measurement_y2006m02 PARTITION OF measurement
               FOR VALUES FROM ('2006-02-01') TO ('2006-03-01');

         CREATE TABLE measurement_y2006m03 PARTITION OF measurement
               FOR VALUES FROM ('2006-03-01') TO ('2006-04-01');

         ...
         CREATE TABLE measurement_y2007m11 PARTITION OF measurement
               FOR VALUES FROM ('2007-11-01') TO ('2007-12-01');

         CREATE TABLE measurement_y2007m12 PARTITION OF measurement
               FOR VALUES FROM ('2007-12-01') TO ('2008-01-01')
               TABLESPACE fasttablespace;

         CREATE TABLE measurement_y2008m01 PARTITION OF measurement
               FOR VALUES FROM ('2008-01-01') TO ('2008-02-01')
               WITH (parallel_workers = 4)
               TABLESPACE fasttablespace;

      为了实现子分区，在创建分区的命令中指定\ ``PARTITION BY``\ 子句，例如：

      .. code:: programlisting

         CREATE TABLE measurement_y2006m02 PARTITION OF measurement
               FOR VALUES FROM ('2006-02-01') TO ('2006-03-01')
               PARTITION BY RANGE (peaktemp);

      在创建了\ ``measurement_y2006m02``\ 的分区之后，任何被插入到\ ``measurement``\ 中且被映射到\ ``measurement_y2006m02``\ 的数据（或者直接被插入到\ ``measurement_y2006m02``\ 的数据，假定它满足这个分区的分区约束）将被基于\ ``peaktemp``\ 列进一步重定向到\ ``measurement_y2006m02``\ 的一个分区。指定的分区键可以与父亲的分区键重叠，不过在指定子分区的边界时要注意它接受的数据集合是分区自身边界允许的数据集合的一个子集，系统不会尝试检查事情情况是否如此。

   3. 在分区表的键列上创建一个索引，还有其他需要的索引（键索引并不是必需的，但是大部分场景中它都能很有帮助）。这会自动在每个分区上创建一个索引，并且后来创建或者附着的任何分区也将会包含索引。

      .. code:: programlisting

         CREATE INDEX ON measurement (logdate);

   4. 确保配置参数在\ ``postgresql.conf``\ 中没有被禁用。如果被禁用，查询将不会按照想要的方式被优化。

在上面的例子中，我们会每个月创建一个新分区，因此写一个脚本来自动生成所需的DDL会更好。

分区维护
++++++++++++++

通常在初始定义分区表时建立的分区并非保持静态不变。移除旧分区的数据并且为新数据周期性地增加新分区的需求比比皆是。分区的最大好处之一就是可以通过操纵分区结构来近乎瞬时地执行这类让人头痛的任务，而不是物理地去除大量数据。

移除旧数据最简单的选择是删除掉不再需要的分区：

.. code:: programlisting

   DROP TABLE measurement_y2006m02;

这可以非常快地删除数百万行记录，因为它不需要逐个删除每个记录。不过要注意上面的命令需要在父表上拿到\ ``ACCESS EXCLUSIVE``\ 锁。

另一种通常更好的选项是把分区从分区表中移除，但是保留它作为一个独立的表：

.. code:: programlisting

   ALTER TABLE measurement DETACH PARTITION measurement_y2006m02;

这允许在它被删除之前在其数据上执行进一步的操作。例如，这通常是一种使用\ ``COPY``\ 、pg_dump或类似工具备份数据的好时候。这也是把数据聚集成较小的格式、执行其他数据操作或者运行报表的好时机。

类似地，我们可以增加一个新分区来处理新数据。我们可以在分区表中创建一个空分区，就像上面创建的初始分区那样：

.. code:: programlisting

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

另外一种选择是，有时候在分区结构之外创建新表更加方便，然后将它作为一个合适的分区。这允许先对数据进行装载、检查和转换，然后再让它们出现在分区表中：

.. code:: programlisting

   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' );

在运行\ ``ATTACH PARTITION``\ 命令之前，推荐在要被挂接的表上创建一个\ ``CHECK``\ 约束来匹配期望的分区约束。
这样，系统将能够跳过扫描来验证隐式分区约束。
没有\ ``CHECK``\ 约束，将扫描表以验证分区约束，同时对该分区持有\ ``ACCESS EXCLUSIVE``\ 锁定，并在父表上持有\ ``SHARE UPDATE EXCLUSIVE``\ 锁。
在完成\ ``ATTACH PARTITION``\ 后，可能需要删除冗余\ ``CHECK``\ 约束。

如上所述，可以在分区的表上创建索引，并自动将其应用于整个层次结构。
这非常便利，因为不仅现有分区将变为索引，而且将来创建的任何分区都将变为索引。
一个限制是，在创建这样一个分区索引时，不可能同时使用\ ``CONCURRENTLY``\ 限定符。
为了克服长时间锁，可以对分区表使用\ ``CREATE INDEX ON ONLY``
;这样的索引被标记为无效，并且分区不会自动应用该索引。
分区上的索引可以使用\ ``CONCURRENTLY``\ 分别的创建。
然后使用\ ``ALTER INDEX .. ATTACH PARTITION``\ *attached*\ 到父索引。
一旦所有分区的索引附加到父索引，父索引将自动标记为有效。 例如：

.. code:: programlisting

   CREATE INDEX measurement_usls_idx ON ONLY measurement (unitsales);

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

该技术也可以与\ ``UNIQUE`` 和\ ``PRIMARY KEY`` 约束一起试用;
当创建约束时隐式创建索引。例如:

.. code:: programlisting

   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;
   ...

限制
++++++++++++++

分区表有下列限制：

.. container:: itemizedlist

   -  没有办法创建跨越所有分区的排除约束，只可能单个约束每个叶子分区。

   -  分区表上的惟一约束必须包括所有分区键列。存在此限制是因为PostgreSQL只能每个分区中分别强制实施唯一性。

   -  如果必要，必须在个体分区上定义\ ``BEFORE ROW``\ 触发器，分区表上不需要。

   -  不允许在同一个分区树中混杂临时关系和持久关系。因此，如果分区表是持久的，则其分区也必须是持久的，反之亦然。在使用临时关系时，分区数的所有成员都必须来自于同一个会话。

使用继承实现
--------------

虽然内建的声明式分区适合于大部分常见的用例，但还是有一些场景需要更加灵活的方法。分区可以使用表继承来实现，这能够带来一些声明式分区不支持的特性，例如：

.. container:: itemizedlist

   -  对声明式分区来说，分区必须具有和分区表正好相同的列集合，而在表继承中，子表可以有父表中没有出现过的额外列。

   -  表继承允许多继承。

   -  声明式分区仅支持范围、列表以及哈希分区，而表继承允许数据按照用户的选择来划分（不过注意，如果约束排除不能有效地剪枝子表，查询性能可能会很差）。

   -  在使用声明式分区时，一些操作比使用表继承时要求更长的持锁时间。例如，向分区表中增加分区或者从分区表移除分区要求在父表上取得一个\ ``ACCESS EXCLUSIVE``\ 锁，而在常规继承的情况下一个\ ``SHARE UPDATE EXCLUSIVE``\ 锁就足够了。

例子
++++++++++++++

我们使用上面用过的同一个\ ``measurement``\ 表。为了使用继承实现分区，可使用下面的步骤：

.. container:: orderedlist

   1. 创建“主”表，所有的“子”表都将从它继承。这个表将不包含数据。不要在这个表上定义任何检查约束，除非想让它们应用到所有的子表上。同样，在这个表上定义索引或者唯一约束也没有意义。对于我们的例子来说，主表是最初定义的\ ``measurement``\ 表。

   2. 创建数个“子”表，每一个都从主表继承。通常，这些表将不会在从主表继承的列集合之外增加任何列。正如声明性分区那样，这些表就是普通的PostgreSQL表（或者外部表）。

      .. code:: programlisting

         CREATE TABLE measurement_y2006m02 () INHERITS (measurement);
         CREATE TABLE measurement_y2006m03 () INHERITS (measurement);
         ...
         CREATE TABLE measurement_y2007m11 () INHERITS (measurement);
         CREATE TABLE measurement_y2007m12 () INHERITS (measurement);
         CREATE TABLE measurement_y2008m01 () INHERITS (measurement);

   3. 为子表增加不重叠的表约束来定义每个分区允许的键值。

      典型的例子是：

      .. code:: programlisting

         CHECK ( x = 1 )
         CHECK ( county IN ( 'Oxfordshire', 'Buckinghamshire', 'Warwickshire' ))
         CHECK ( outletID >= 100 AND outletID < 200 )

      确保约束能保证不同子表允许的键值之间没有重叠。设置范围约束的常见错误：

      .. code:: programlisting

         CHECK ( outletID BETWEEN 100 AND 200 )
         CHECK ( outletID BETWEEN 200 AND 300 )

      这是错误的，因为不清楚键值200属于哪一个子表。

      像下面这样创建子表会更好：

      .. code:: programlisting

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

         CREATE TABLE measurement_y2006m03 (
               CHECK ( logdate >= DATE '2006-03-01' AND logdate < DATE '2006-04-01' )
         ) INHERITS (measurement);

         ...
         CREATE TABLE measurement_y2007m11 (
               CHECK ( logdate >= DATE '2007-11-01' AND logdate < DATE '2007-12-01' )
         ) INHERITS (measurement);

         CREATE TABLE measurement_y2007m12 (
               CHECK ( logdate >= DATE '2007-12-01' AND logdate < DATE '2008-01-01' )
         ) INHERITS (measurement);

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

   4. 对于每个子表，在键列上创建一个索引，以及任何想要的其他索引。

      .. code:: programlisting

         CREATE INDEX measurement_y2006m02_logdate ON measurement_y2006m02 (logdate);
         CREATE INDEX measurement_y2006m03_logdate ON measurement_y2006m03 (logdate);
         CREATE INDEX measurement_y2007m11_logdate ON measurement_y2007m11 (logdate);
         CREATE INDEX measurement_y2007m12_logdate ON measurement_y2007m12 (logdate);
         CREATE INDEX measurement_y2008m01_logdate ON measurement_y2008m01 (logdate);

   5. 我们希望我们的应用能够使用\ ``INSERT INTO measurement ...``\ 并且数据将被重定向到合适的分区表。我们可以通过为主表附加一个合适的触发器函数来实现这一点。如果数据将只被增加到最后一个分区，我们可以使用一个非常简单的触发器函数：

      .. code:: programlisting

         CREATE OR REPLACE FUNCTION measurement_insert_trigger()
         RETURNS TRIGGER AS $$
         BEGIN
               INSERT INTO measurement_y2008m01 VALUES (NEW.*);
               RETURN NULL;
         END;
         $$
         LANGUAGE plpgsql;

      完成函数创建后，我们创建一个调用该触发器函数的触发器：

      .. code:: programlisting

         CREATE TRIGGER insert_measurement_trigger
               BEFORE INSERT ON measurement
               FOR EACH ROW EXECUTE FUNCTION measurement_insert_trigger();

      我们必须在每个月重新定义触发器函数，这样它才会总是指向当前的子表。而触发器的定义则不需要被更新。

      我们也可能希望插入数据时服务器会自动地定位应该加入数据的子表。我们可以通过一个更复杂的触发器函数来实现之，例如：

      .. code:: programlisting

         CREATE OR REPLACE FUNCTION measurement_insert_trigger()
         RETURNS TRIGGER AS $$
         BEGIN
               IF ( NEW.logdate >= DATE '2006-02-01' AND
                  NEW.logdate < DATE '2006-03-01' ) THEN
                  INSERT INTO measurement_y2006m02 VALUES (NEW.*);
               ELSIF ( NEW.logdate >= DATE '2006-03-01' AND
                     NEW.logdate < DATE '2006-04-01' ) THEN
                  INSERT INTO measurement_y2006m03 VALUES (NEW.*);
               ...
               ELSIF ( NEW.logdate >= DATE '2008-01-01' AND
                     NEW.logdate < DATE '2008-02-01' ) THEN
                  INSERT INTO measurement_y2008m01 VALUES (NEW.*);
               ELSE
                  RAISE EXCEPTION 'Date out of range.  Fix the measurement_insert_trigger() function!';
               END IF;
               RETURN NULL;
         END;
         $$
         LANGUAGE plpgsql;

      触发器的定义和以前一样。注意每一个\ ``IF``\ 测试必须准确地匹配它的子表的\ ``CHECK``\ 约束。

      当该函数比单月形式更加复杂时，并不需要频繁地更新它，因为可以在需要的时候提前加入分支。

      .. note::

         .. rubric:: 注意
            :name: 注意
            :class: title

         在实践中，如果大部分插入都会进入最新的子表，最好先检查它。为了简洁，我们为触发器的检查采用了和本例中其他部分一致的顺序。

      把插入重定向到一个合适的子表中的另一种不同方法是在主表上设置规则而不是触发器。例如：

      .. code:: programlisting

         CREATE RULE measurement_insert_y2006m02 AS
         ON INSERT TO measurement WHERE
               ( logdate >= DATE '2006-02-01' AND logdate < DATE '2006-03-01' )
         DO INSTEAD
               INSERT INTO measurement_y2006m02 VALUES (NEW.*);
         ...
         CREATE RULE measurement_insert_y2008m01 AS
         ON INSERT TO measurement WHERE
               ( logdate >= DATE '2008-01-01' AND logdate < DATE '2008-02-01' )
         DO INSTEAD
               INSERT INTO measurement_y2008m01 VALUES (NEW.*);

      规则的开销比触发器大很多，但是这种开销是每个查询只有一次，而不是每行一次，因此这种方法可能对批量插入的情况有优势。不过，在大部分情况下，触发器方法将提供更好的性能。

      注意\ ``COPY``\ 会忽略规则。如果想要使用\ ``COPY``\ 插入数据，则需要拷贝到正确的子表而不是直接放在主表中。\ ``COPY``\ 会引发触发器，因此在使用触发器方法时可以正常使用它。

      规则方法的另一个缺点是，如果规则集合无法覆盖插入日期，则没有简单的方法能够强制产生错误，数据将会无声无息地进入到主表中。

   6. 确认\ `constraint_exclusion `__\ 配置参数在\ ``postgresql.conf``\ 中没有被禁用，否则将会不必要地访问子表。

如我们所见，一个复杂的表层次可能需要大量的DDL。在上面的例子中，我们可能为每个月创建一个新的子表，因此编写一个脚本来自动生成所需要的DDL可能会更好。

继承分区的维护
++++++++++++++

要快速移除旧数据，只需要简单地去掉不再需要的子表：

.. code:: programlisting

   DROP TABLE measurement_y2006m02;

要从继承层次表中去掉子表，但还是把它当做一个表保留：

.. code:: programlisting

   ALTER TABLE measurement_y2006m02 NO INHERIT measurement;

要增加一个新子表来处理新数据，可以像上面创建的原始子表那样创建一个空的子表：

.. code:: programlisting

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

或者，用户可能想要创建新子表并且在将它加入到表层次之前填充它。这可以允许数据在被父表上的查询可见之前对数据进行装载、检查以及转换。

.. code:: programlisting

   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;

提醒
++++++++++++++

下面的提醒适用于用继承实现的分区：

.. container:: itemizedlist

   -  没有自动的方法啊验证所有的\ ``CHECK``\ 约束之间是否互斥。编写代码来产生子表以及创建和修改相关对象比手写命令要更加安全。

   -  索引和外键约束适用于单个表而不是其继承子级，因此它们有一些\ `caveats <ddl-inherit.html#DDL-INHERIT-CAVEATS>`__
      需要注意。

   -  这里展示的模式假定行的键列值从不改变，或者说改变不足以让行移动到另一个分区。由于\ ``CHECK``\ 约束的存在，尝试那样做的\ ``UPDATE``\ 将会失败。如果需要处理那种情况，可以在子表上放置适当的更新触发器，但是那会使对结构的管理更加复杂。

   -  如果使用手工的\ ``VACUUM``\ 或者\ ``ANALYZE``\ 命令，不要忘记需要在每个子表上单独运行它们。这样的命令：

      .. code:: programlisting

         ANALYZE measurement;

      将只会处理主表。

   -  带有\ ``ON CONFLICT``\ 子句的\ ``INSERT``\ 语句不太可能按照预期工作，因为只有在指定的目标关系而不是其子关系上发生唯一违背时才会采取\ ``ON CONFLICT``\ 行动。

   -  将会需要触发器或者规则将行路由到想要的子表中，除非应用明确地知道分区的模式。编写触发器可能会很复杂，并且会比声明式分区在内部执行的元组路由慢很多。

分区剪枝
++++++++++++++


*分区剪枝*\ 是一种提升声明式分区表性能的查询优化技术。例如：

.. code:: programlisting

   SET enable_partition_pruning = on;                 -− the default
   SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';

如果没有分区剪枝，上面的查询将会扫描\ ``measurement``\ 表的每一个分区。如果启用了分区剪枝，规划器将会检查每个分区的定义并且检验该分区是否因为不包含符合查询\ ``WHERE``\ 子句的行而无需扫描。当规划器可以证实这一点时，它会把分区从查询计划中排除（\ *剪枝*\ ）。

通过使用EXPLAIN命令和\ `enable_partition_pruningd`__\ 配置参数，可以展示剪枝掉分区的计划与没有剪枝的计划之间的差别。对这种类型的表设置，一种典型的未优化计划是：

.. code:: programlisting

   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)

某些或者全部的分区可能会使用索引扫描取代全表顺序扫描，但是这里的重点是根本不需要扫描较老的分区来回答这个查询。当我们启用分区剪枝时，我们会得到一个便宜很多的计划，而它能给出相同的答案：

.. code:: programlisting

   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``\ 语句中定义的参数会使用从子查询拿到的值，或者嵌套循环连接内侧关系上的参数化值。
执行期间的分区剪枝可能在下列任何时刻执行：

.. container:: itemizedlist

   -  在查询计划的初始化期间。对于执行的初始化阶段就已知值的参数，可以在这里执行分区剪枝。这个阶段中被剪枝掉的分区将不会显示在查询的\ ``EXPLAIN``\ 或\ ``EXPLAIN ANALYZE``\ 结果中。通过观察\ ``EXPLAIN``\ 输出的“Subplans
      Removed”属性，可以确定被剪枝掉的分区数。

   -  在查询计划的实际执行期间。这里可以使用只有在实际查询执行时才能知道的值执行分区剪枝。这包括来自子查询的值以及来自执行时参数的值（例如来自于参数化嵌套循环连接的参数）。由于在查询执行期间这些参数的值可能会改变多次，所以只要分区剪枝使用到的执行参数发生改变，就会执行一次分区剪枝。要判断分区是否在这个阶段被剪枝，需要仔细地观察\ ``EXPLAIN ANALYZE``\ 输出中的\ ``loops``\ 属性。
      对应于不同分区的子计划可以具有不同的值，这取决于在执行期间每个分区被修剪的次数。
      如果每次都被剪枝，有些分区可能会显示为\ ``(never executed)``\ 。

可以使用\ `enable_partition_pruning`__\ 设置禁用分区剪枝。

.. note::

   .. rubric:: 注意
      :name: 注意-1
      :class: title

   执行时间分区裁剪当前只针对\ ``Append``\ 和\ ``MergeAppend``\ 节点类型。
   它还没有为\ ``ModifyTable``\ 节点类型实现，但有可能会在将来发布的
   PostgreSQL中更改。

分区和约束排除
++++++++++++++

*约束排除*\ 是一种与分区剪枝类似的查询优化技术。虽然它主要被用于使用传统继承方法实现的分区上，但它也可以被用于其他目的，包括用于声明式分区。

约束排除以非常类似于分区剪枝的方式工作，不过它使用每个表的\ ``CHECK``\ 约束
— 这也是它得名的原因 —
而分区剪枝使用表的分区边界，分区边界仅存在于声明式分区的情况中。另一点不同之处是约束排除仅在规划时应用，在执行时不会尝试移除分区。

由于约束排除使用\ ``CHECK``\ 约束，这导致它比分区剪枝要慢，但有时候可以被当作一种优点加以利用：因为甚至可以在声明式分区的表上（在分区边界之外）定义约束，约束排除可能可以从查询计划中消去额外的分区。

`constraint_exclusion`__\ 的默认（也是推荐的）设置不是\ ``on``\ 也不是\ ``off``\ ，而是一种被称为\ ``partition``\ 的中间设置，这会导致该技术仅被应用于可能工作在继承分区表上的查询。\ ``on``\ 设置导致规划器检查所有查询中的\ ``CHECK``\ 约束，甚至是那些不太可能受益的简单查询。

下列提醒适用于约束排除：

.. container:: itemizedlist

   -  约束排除仅适用于查询规划期间，和分区裁剪不同，在查询执行期间也可以应用。

   -  只有查询的\ ``WHERE``\ 子句包含常量（或者外部提供的参数）时，约束排除才能有效果。例如，针对一个非不变函数（如\ ``CURRENT_TIMESTAMP``\ ）的比较不能被优化，因为规划器不知道该函数的值在运行时会落到哪个子表中。

   -  保持分区约束简单化，否则规划器可能无法验证哪些子表可能不需要被访问。如前面的例子所示，对列表分区使用简单的等值条件，对范围分区使用简单的范围测试。一种好的经验规则是分区约束应该仅包含分区列与常量使用B-树的可索引操作符的比较，因为只有B-树的可索引列才允许出现在分区键中。

   -  约束排除期间会检查父表的所有子表上的所有约束，因此大量的子表很可能明显地增加查询规划时间。因此，传统的基于继承的分区可以很好地处理上百个子表，不要尝试使用上千个子表。

声明分区最佳实践
++++++++++++++

应该谨慎地选择如何划分表，因为查询规划和执行的性能可能会受到不良设计的负面影响。

最重要的设计决策之一是列或者如和对数据进行分区的。
通常最佳选择是按列或列集合进行分区，这些列最常出现在分区表上执行的查询的
``WHERE``\ 子句中。
``WHERE``\ 子句项与分区键匹配并兼容，可用于裁剪不需要的分区。
但是，你可能会被迫根据\ ``PRIMARY KEY``\ 或\ ``UNIQUE``\ 约束的要求做出其他决策。
在规划分区策略时，删除不需要的数据也是需要考虑的一个因素。
可以相当快地分离整个分区，因此采用这样方式设计分区策略可能是有益的，既把一次删除的所有数据都放在单个分区中。

选择表应该划分的分区的目标数量也是一个重要的决策。
没有足够的分区可能意味着索引仍然太大，数据位置仍然较差，这可能导致缓存命中率很低。
但是，将表划分为太多的分区也会导致问题。
在查询规划和执行期间，过多的分区可能意味着查询计划时间较长，内存消耗也更高。
在选择如何划分表时，考虑将来可能发生的更改也很重要。
例如，如果您选择为每个客户提供一个分区，而您目前只有少量的大客户，那么，如果几年后您发现自己有大量的小客户，那么就要考虑这种影响。
在这种情况下，最好选择按\ ``HASH``\ 分区并且选择合理数量的分区，而不是尝试按
``LIST``
进行分区，并希望客户数量的增长不会超出按数据分区的实际范围。

子分区可用于进一步划分预期会比其他分区更大的分区，尽管过多的子分区很容易导致大量分区，并可能导致前一段中提到的相同问题。

考虑查询计划和执行期间的分区开销也很重要。
查询规划器通常能够很好地处理多达几千个分区的分区层次结构，前提是典型的查询允许查询规划器裁剪除了少量分区之外的所有分区。
规划器执行分区修剪后保留更多分区时，规划时间会变长，内存消耗会更高。对于\ ``UPDATE``
和 ``DELETE``\ 命令尤其如此。
担心拥有大量分区的另一个原因是，服务器的内存消耗可能会在一段时间内显著增加，特别是如果许多会话接触大量分区。
这是因为每个分区都需要将其元数据加载到接触它的每个会话的本地内存中。

对于数据仓库类型工作负载，使用比 OLTP
类型工作负载更多的分区数量很有意义。
通常，在数据仓库中，查询计划时间不太值得关注，因为大多数处理时间都花在查询执行期间。
对于这两种类型的工作负载，尽早做出正确的决策非常重要，因为重新分区大量数据可能会非常缓慢。
模拟预期工作负载通常有利于优化分区策略。永远不要假设更多的分区比更少的分区更好，反之亦然。