Supongamos que almacenas los registros de acceso del servidor web en una base de datos. La mayoría de los accesos provienen del rango de direcciones IP de tu organización, pero algunos son de otros lugares (por ejemplo, empleados con conexiones de marcado telefónico). Si tus búsquedas por IP son principalmente para accesos externos, probablemente no necesites indexar el rango de IP que corresponde a la subred de tu organización.

Asume una tabla como esta:

CREATE TABLE access_log (
    url varchar,
    client_ip inet,
    ...
);

Para crear un índice parcial que se adapte a nuestro ejemplo, usa un comando como este:

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');

Una consulta típica que puede usar este índice sería:

SELECT *
FROM access_log
WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';

Aquí la dirección IP de la consulta está cubierta por el índice parcial. La siguiente consulta no puede usar el índice parcial, ya que utiliza una dirección IP que está excluida del índice:

SELECT *
FROM access_log
WHERE url = '/index.html' AND client_ip = inet '192.168.100.23';

Observa que este tipo de índice parcial requiere que los valores comunes estén predeterminados, por lo que tales índices parciales se utilizan mejor para distribuciones de datos que no cambian. Estos índices se pueden volver a crear ocasionalmente para ajustarse a las nuevas distribuciones de datos, pero esto añade un esfuerzo de mantenimiento.

Si tienes una tabla que contiene tanto pedidos facturados como no facturados, donde los pedidos no facturados ocupan una pequeña fracción del total de la tabla y, sin embargo, esas son las filas a las que más se accede, puedes mejorar el rendimiento creando un índice solo en las filas no facturadas. El comando para crear el índice se vería así:

CREATE INDEX orders_unbilled_index ON orders (order_nr)
    WHERE billed is not true;

Una posible consulta para usar este índice sería:

SELECT * FROM orders WHERE billed is not true AND order_nr < 10000;

Sin embargo, el índice también se puede usar en consultas que no involucren a order_nr en absoluto, por ejemplo:

SELECT * FROM orders WHERE billed is not true AND amount > 5000.00;

Esto no es tan eficiente como lo sería un índice parcial en la columna amount, ya que el sistema tiene que escanear todo el índice. Sin embargo, si hay relativamente pocos pedidos no facturados, usar este índice parcial solo para encontrar los pedidos no facturados podría ser una ganancia.

Ten en cuenta que esta consulta no puede usar este índice:

SELECT * FROM orders WHERE order_nr = 3501;

El pedido 3501 podría estar entre los pedidos facturados o no facturados.

Supongamos que tenemos una tabla que describe los resultados de las pruebas. Queremos asegurarnos de que solo haya una entrada “exitosa” para una combinación dada de sujeto y objetivo, pero puede haber cualquier número de entradas “no exitosas”. Aquí hay una manera de hacerlo:

CREATE TABLE tests (
    subject text,
    target text,
    success boolean,
    ...
);

CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
    WHERE success;

Este es un enfoque particularmente eficiente cuando hay pocas pruebas exitosas y muchas no exitosas. También es posible permitir solo un nulo en una columna creando un índice parcial único con una restricción IS NULL.

Podrías sentirte tentado a crear un gran conjunto de índices parciales que no se solapen, por ejemplo:

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;

¡Esta es una mala idea! Casi con seguridad, te irá mejor con un solo índice no parcial, declarado como:

CREATE INDEX mytable_cat_data ON mytable (category, data);

(Coloca la columna de la categoría primero, por las razones descritas en Section 11.3). Aunque una búsqueda en este índice más grande tenga que descender a través de un par de niveles de árbol más que una búsqueda en un índice más pequeño, casi con seguridad eso será más barato que el esfuerzo del planificador necesario para seleccionar el índice parcial adecuado. El núcleo del problema es que el sistema no entiende la relación entre los índices parciales y probará laboriosamente cada uno para ver si es aplicable a la consulta actual.

Si tu tabla es lo suficientemente grande como para que un solo índice sea realmente una mala idea, deberías considerar usar particionamiento en su lugar (consulta Section 5.12). Con ese mecanismo, el sistema sí entiende que las tablas y los índices no se solapan, por lo que es posible un rendimiento mucho mejor.