假设您正在数据库中存储 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 可能在已开单或未开单订单中。

假设我们有一个描述测试结果的表。我们希望确保对于给定的主题和目标组合只有一个 “成功” 条目，但可能存在任意数量的 “不成功” 条目。以下是一种实现方法

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

（出于 第 11.3 节 中描述的原因，将类别列放在第一位。）虽然在这个较大的索引中进行搜索可能必须下降几个树级别，但几乎肯定比选择适当的部分索引所需的规划器工作要便宜。问题的核心是系统不了解部分索引之间的关系，并且会费力地测试每个索引以查看它是否适用于当前查询。

如果您的表足够大，以至于单个索引确实不是一个好主意，那么您应该考虑使用分区（请参阅 第 5.12 节）。使用该机制，系统确实理解表和索引是非重叠的，因此可以实现更好的性能。