Es como si leyera de jjanes en otro lugar:un índice de expresión solo se considera si la expresión coincide exactamente con el predicado de consulta. El planificador de consultas de Postgres no es una IA. Anularía rápidamente el propósito de hacer consultas rápidas si su planificación lleva demasiado tiempo.
Puede optimizar un poco su índice, si le sirve de consuelo. left() es más simple y rápido que substring() :
CREATE INDEX record_changes_log_detail_old_value_ix_btree
ON record_changes_log_detail (left(old_value,1024) text_pattern_ops);
Además, hay un tamaño máximo de fila de 2704 bytes para índices btree, no un "límite de 2172 caracteres en árboles B" .
Lo más importante, solo para verificaciones de igualdad, como sugiere su pregunta, un índice btree en un valor hash usando md5(old_value) o hashtext(old_value) sería mucho más eficiente. Si lo hace, recuerde defenderse de las colisiones de hash así:
SELECT *
FROM record_changes_log_detail
WHERE hashtext(old_value) = hashtext('Gold Kerrison Neuro')
AND old_value = 'Gold Kerrison Neuro';El primer predicado le brinda acceso rápido al índice. El segundo excluye los falsos positivos. Las colisiones deberían ser extremadamente raras. Pero posible. Y la posibilidad crece con el tamaño de la mesa.
Relacionado:
- La consulta SELECT con DISTINCT en una estructura de tabla para gráficos es muy lenta
- ¿Cuál es el tipo de datos óptimo para un campo MD5?
- Búsqueda de texto completo en CouchDB
O un índice hash como el que ya te has estado considerando:
- ¿Por qué un índice hash de Postgres 11 es tan grande?
(Aquí no necesita preocuparse por las colisiones de hash; se maneja internamente).
