Предположим, что вы храните журналы доступа к веб-серверу в базе данных. Большинство доступов происходят из диапазона 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;

Это особенно эффективный подход, когда есть немного успешных тестов и много неудачных. Также возможно разрешить только одно значение NULL в столбце, создав уникальный частичный индекс с ограничением 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.11). С помощью этого механизма система понимает, что таблицы и индексы не перекрываются, поэтому возможна гораздо более эффективная работа.