假設您將 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 節）。使用該機制，系統會理解表和索引是不重疊的，因此可以實現更好的效能。