La respuesta depende de muchos factores, como la versión, la codificación y la configuración regional de Postgres:LC_COLLATE en particular.
La expresión simple lower(description) LIKE '%abc%' suele ser un poco más rápido que description ILIKE '%abc%' , y es un poco más rápido que la expresión regular equivalente:description ~* 'abc' . Esto es importante para los escaneos secuenciales donde la expresión debe evaluarse para cada fila probada.
Pero para tablas grandes como las que demuestra en su respuesta, uno ciertamente usaría un índice. Para patrones arbitrarios (no solo anclados a la izquierda) sugiero un índice de trigrama usando el módulo adicional pg_trgm . Entonces hablamos de milisegundos en lugar de segundos y se anula la diferencia entre las expresiones anteriores.
Índices GIN y GiST (usando el gin_trgm_ops o gist_trgm_ops clases de operadores) admite LIKE (~~ ), ILIKE (~~* ), ~ , ~* (y algunas variantes más) por igual. Con un índice GIN de trigrama en description (generalmente más grande que GiST, pero más rápido para lecturas), su consulta usaría description ILIKE 'case_insensitive_pattern' .
Relacionado:
- Variaciones de rendimiento de consultas LIKE de PostgreSQL
- Cadenas UTF-8 similares para el campo de autocompletar
Conceptos básicos para la coincidencia de patrones en Postgres:
- Coincidencia de patrones con LIKE, SIMILAR TO o expresiones regulares en PostgreSQL
Cuando se trabaja con dicho índice de trigramas, normalmente más práctico para trabajar con:
description ILIKE '%abc%'
O con el operador regexp que no distingue entre mayúsculas y minúsculas (sin % comodines):
description ~* 'abc'
Un índice en (description) no admite consultas en lower(description) como:
lower(description) LIKE '%abc%'
Y viceversa.
Con predicados en lower(description) exclusivamente , el índice de expresión es una opción ligeramente mejor.
En todos los demás casos, un índice en (description) es preferible ya que es compatible con ambos predicados sensibles a mayúsculas y minúsculas.
