Postgres 9.2 o posterior generalmente es lo suficientemente inteligente como para darse cuenta de que la condición
WHERE name LIKE '%%'
no es selectivo y recurre a un escaneo secuencial que ignora el índice GiST, incluso con declaraciones preparadas. Tu haces sin embargo, pague un pequeño precio por la condición inútil.
En Postgres 9.1 o anterior, crearía una consulta separada para el caso especial.
Compara las Notas sección para PREPARE declaración en el manual para las versiones 9.1
, 9.2
y 9.3
.
Verifíquese
Prepare la declaración y ejecute EXPLAIN ANALYZE para probar:
PREPARE plan1 (text) AS
SELECT * FROM file
WHERE name LIKE $1;
EXPLAIN ANALYZE EXECUTE plan1('%123%');
EXPLAIN ANALYZE EXECUTE plan1('%%');
Los planes generalmente se almacenan en caché durante la duración de la sesión.
Consulta alternativa
Independientemente de la versión que esté ejecutando, si siempre realiza una búsqueda de texto completo (comodines a la izquierda y a la derecha), esta consulta debería ser más rápida para una declaración preparada:
SELECT * FROM files WHERE name LIKE ('%' || $1 || '%');
Y pase el patrón sin comodines añadidos (% ), por supuesto. De esta forma, Postgres sabe que debe esperar un patrón encerrado entre comodines en el momento de la planificación.
->Demostración de SQLfiddle.
Observe el escaneo secuencial para el LIKE vacío y la diferencia de rendimiento entre los dos planes.
SQLfiddle varía mucho, dependiendo de la carga, etc. Una sola ejecución puede no ser confiable. Pruebe mejor en su entorno y ejecute cada declaración un par de veces para saturar el caché y eliminar el ruido.
