假设您将 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约束的唯一部分索引，也可以只允许一列为 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 节）。使用该机制，系统会理解表和索引是不重叠的，因此可以实现更好的性能。