假设你把 Web 服务器访问日志存储在数据库中。大多数访问来自你所在组织的 IP 地址范围，但也有一些来自其他地方（例如使用拨号连接的员工）。如果你按 IP 搜索时主要关心外部访问，那么你大概没有必要为对应于组织内子网的 IP 范围建索引。

假设有一个如下表：

CREATE TABLE access_log (
    url varchar,
    client_ip inet,
    ...
);

要创建一个适合这个例子的部分索引，可使用如下命令：

CREATE INDEX access_log_client_ip_ix ON access_log (client_ip)
WHERE NOT (client_ip > inet '192.168.100.0' AND
           client_ip < inet '192.168.100.255');

一个可以使用该索引的典型查询是：

SELECT *
FROM access_log
WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';

这里查询中的 IP 地址落在部分索引覆盖的范围内。下面这个查询则不能使用该部分索引，因为它使用了一个被索引排除掉的 IP 地址：

SELECT *
FROM access_log
WHERE url = '/index.html' AND client_ip = inet '192.168.100.23';

请注意，这类部分索引要求常见值事先可知，因此最适合用于数据分布不会变化的场景。也可以偶尔重建这类索引以适应新的数据分布，但那会增加维护工作量。

如果你有一张表，其中同时包含已开账单和未开账单的订单，而未开账单订单只占整张表的一小部分，却是最常被访问的那些行，那么你可以通过只为未开账单的行创建索引来提升性能。创建该索引的命令如下：

CREATE INDEX orders_unbilled_index ON orders (order_nr)
    WHERE billed is not true;

一个可能会使用该索引的查询是：

SELECT * FROM orders WHERE billed is not true AND order_nr < 10000;

不过，这个索引也可以用于那些完全不涉及order_nr的查询，例如：

SELECT * FROM orders WHERE billed is not true AND amount > 5000.00;

这不像在amount列上建立部分索引那样高效，因为系统必须扫描整个索引。不过，如果未开账单的订单相对较少，那么即使只是用这个部分索引来找出未开账单订单，也可能是值得的。

请注意，下面这个查询不能使用该索引：

SELECT * FROM orders WHERE order_nr = 3501;

因为订单 3501 可能属于已开账单订单，也可能属于未开账单订单。

假设我们有一张描述测试结果的表。我们希望确保对于给定的subject和target组合，只有一条“成功”记录，但可以有任意多条“失败”记录。实现方法之一如下：

CREATE TABLE tests (
    subject text,
    target text,
    success boolean,
    ...
);

CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
    WHERE success;

当成功测试很少而失败测试很多时，这是一种特别高效的方法。也可以通过创建一个带IS NULL限制的唯一部分索引，来让某一列只允许出现一个空值。

你可能会想创建一大组互不重叠的部分索引，例如

CREATE INDEX mytable_cat_1 ON mytable (data) WHERE category = 1;
CREATE INDEX mytable_cat_2 ON mytable (data) WHERE category = 2;
CREATE INDEX mytable_cat_3 ON mytable (data) WHERE category = 3;
...
CREATE INDEX mytable_cat_N ON mytable (data) WHERE category = N;

这是个坏主意！几乎可以肯定，你最好建立一个单独的非部分索引，例如：

CREATE INDEX mytable_cat_data ON mytable (category, data);

（把 category 列放在前面，原因见Section 11.3。）虽然在这个较大的索引中搜索，可能要比在较小索引中搜索多下降几层树，但这几乎肯定仍然比规划器为了从这些部分索引中选出合适的一个所付出的代价更低。问题的核心在于，系统并不了解这些部分索引之间的关系，因此会费力地逐个测试它们，看它们是否适用于当前查询。

如果你的表大到单个索引确实不是好主意，那么你应该考虑改用分区（见Section 5.12）。借助这种机制，系统能够理解这些表和索引彼此不重叠，因此有可能获得好得多的性能。