假设您正在数据库中存储 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 节）。使用这种机制，系统确实理解表和索引是不重叠的，因此可以实现更好的性能。