假設您將網站伺服器存取日誌儲存在資料庫中。大多數存取來自您組織的 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 可能屬於已收費或未收費訂單。

假設我們有一個描述測試結果的表格。 我們希望確保給定的主體和目標組合只有一個「“successful”」條目，但可能會有任意數量的「“unsuccessful”」條目。以下是一種方法：

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 節 中描述的原因，請將 category 欄位放在首位。）雖然在這個較大的索引中進行搜尋可能需要比在較小索引中進行搜尋下降更多層樹狀結構，但幾乎可以肯定這比選擇適當的部分索引所需的計畫器工作量要便宜。 問題的核心在於系統不了解部分索引之間的關係，並且會費力地測試每個索引以查看它是否適用於當前查詢。

如果您的表格足夠大，以至於單個索引確實是個壞主意，則應考慮使用分割區（請參閱第 5.12 節）。使用該機制，系統確實了解表格和索引是不重疊的，因此可以實現更好的效能。