分区是指将逻辑上的一个大表拆分成较小的物理部分。分区可以带来以下好处：

通常只有表本身非常大时，这些好处才值得考虑。表从多大开始受益于分区，取决于具体应用；不过，一条经验法则是表的大小应超过数据库服务器的物理内存。

目前，PostgreSQL通过表继承来支持分区。每个分区都必须作为单个父表的子表创建。父表本身通常为空；它的存在只是为了表示整个数据集。在尝试设置分区之前，你应当先熟悉继承（见第 5.8 节）。

在PostgreSQL中可以实现以下几种分区形式：

要设置一个分区表，可以按以下步骤操作：

例如，假设正在为一家大型冰淇淋公司构建数据库。该公司每天测量最高温度，并统计各个地区的冰淇淋销量。从概念上看，我们需要如下表：

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

我们知道，大多数查询只会访问最近一周、一个月或一个季度的数据，因为该表主要用于为管理层生成在线报表。为减少需要存储的旧数据量，决定只保留最近 3 年的数据，并在每月月初删除最早一个月的数据。

在这种情况下，可以利用分区来帮助满足测量表的各种不同需求。按照上面概述的步骤，可以这样设置分区：

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

通常，最初定义表时建立的分区集合并不会保持不变。常见的需求是删除旧数据分区，并定期为新数据添加新分区。分区最重要的优势之一，恰恰在于它允许通过操纵分区结构，而不是物理地移动大量数据，来近乎瞬时地完成这种原本非常痛苦的任务。

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

DROP TABLE measurement_y2006m02;

由于不必逐条删除每条记录，这可以非常快速地删除数百万条记录。

另一种通常更可取的选择，是将该分区从分区表中移除，但保留它作为独立表的可访问性：

ALTER TABLE measurement_y2006m02 NO INHERIT measurement;

这样在删除数据之前，还可以对其执行进一步的操作。例如，这常常是使用COPY、pg_dump或类似工具备份数据的好时机。也可能是把数据聚合成更小格式、执行其他数据处理或运行报告的好时机。

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

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 constraint_exclusion = on;
SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';

如果没有约束排除，上述查询会扫描measurement表的每个分区。启用约束排除后，规划器会检查每个分区的约束，并尝试证明该分区不需要扫描，因为它不可能包含满足查询WHERE子句的行。如果规划器能够证明这一点，就会将该分区排除在查询计划之外。

可以使用EXPLAIN命令，显示启用constraint_exclusion时的计划与禁用时的计划之间的差异。对于这种表结构，典型的未优化计划如下：

SET constraint_exclusion = off;
EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';

                                          QUERY PLAN
-----------------------------------------------------------------------------------------------
 Aggregate  (cost=158.66..158.68 rows=1 width=0)
   ->  Append  (cost=0.00..151.88 rows=2715 width=0)
         ->  Seq Scan on measurement  (cost=0.00..30.38 rows=543 width=0)
               Filter: (logdate >= '2008-01-01'::date)
         ->  Seq Scan on measurement_y2006m02 measurement  (cost=0.00..30.38 rows=543 width=0)
               Filter: (logdate >= '2008-01-01'::date)
         ->  Seq Scan on measurement_y2006m03 measurement  (cost=0.00..30.38 rows=543 width=0)
               Filter: (logdate >= '2008-01-01'::date)
...
         ->  Seq Scan on measurement_y2007m12 measurement  (cost=0.00..30.38 rows=543 width=0)
               Filter: (logdate >= '2008-01-01'::date)
         ->  Seq Scan on measurement_y2008m01 measurement  (cost=0.00..30.38 rows=543 width=0)
               Filter: (logdate >= '2008-01-01'::date)

某些或全部分区可能使用索引扫描，而不是全表顺序扫描，但这里的重点是，为回答该查询，根本不需要扫描较旧的分区。启用约束排除后，可以得到代价明显更低、结果却相同的计划：

SET constraint_exclusion = on;
EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
                                          QUERY PLAN
-----------------------------------------------------------------------------------------------
 Aggregate  (cost=63.47..63.48 rows=1 width=0)
   ->  Append  (cost=0.00..60.75 rows=1086 width=0)
         ->  Seq Scan on measurement  (cost=0.00..30.38 rows=543 width=0)
               Filter: (logdate >= '2008-01-01'::date)
         ->  Seq Scan on measurement_y2008m01 measurement  (cost=0.00..30.38 rows=543 width=0)
               Filter: (logdate >= '2008-01-01'::date)

注意，约束排除只由CHECK约束驱动，与是否存在索引无关。因此，不必在键列上定义索引。是否需要为某个分区创建索引，取决于预期查询扫描该分区时通常会扫描其中的大部分，还是仅扫描一小部分。后一种情况下索引会有帮助，前一种情况下则不会。

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

将插入重定向到适当分区表的另一种方法，是在根表上设置规则来代替触发器。例如：

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会引发触发器，因此在使用触发器方法时可以正常使用它。

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

也可以使用UNION ALL视图来安排分区，而不是使用表继承。例如：

CREATE VIEW measurement AS
          SELECT * FROM measurement_y2006m02
UNION ALL SELECT * FROM measurement_y2006m03
...
UNION ALL SELECT * FROM measurement_y2007m11
UNION ALL SELECT * FROM measurement_y2007m12
UNION ALL SELECT * FROM measurement_y2008m01;

但是，重新创建视图的需要给数据集分区的添加和删除增加了一个额外步骤。实践中，与使用继承相比，这种方法没有什么可取之处。

分区表有以下注意事项：

约束排除有以下注意事项：