Se destacan algunos problemas:
Primero, considere actualizar a una versión actual de Postgres . Al momento de escribir, eso es pg 9.6 o pg 10 (actualmente beta). Desde Pg 9.4 ha habido múltiples mejoras para los índices GIN, el módulo adicional pg_trgm y big data en general.
A continuación, necesita mucha más RAM , en particular un work_mem más alto ajuste. Puedo decirlo por esta línea en EXPLAIN salida:
Heap Blocks: exact=7625 lossy=223807
"perdido" en los detalles de un Bitmap Heap Scan (con sus números particulares) indica una escasez dramática de work_mem . Postgres solo recopila direcciones de bloque en el escaneo de índice de mapa de bits en lugar de punteros de fila porque se espera que sea más rápido con su work_mem bajo configuración (no puede contener direcciones exactas en la RAM). Se deben filtrar muchas más filas que no califican en el siguiente análisis del montón de mapa de bits Por aquí. Esta respuesta relacionada tiene detalles:
Pero no configures work_mem también alto sin considerar toda la situación:
Puede haber otros problemas, como el índice o la tabla, o más cuellos de botella de configuración. Pero si corrige solo estos dos elementos, la consulta debería ser mucho ya más rápido.
Además, ¿realmente necesita recuperar las 40k filas del ejemplo? Probablemente quieras agregar un pequeño LIMIT a la consulta y convertirla en una búsqueda de "vecino más cercano", en cuyo caso un índice GiST es la mejor opción después de todo, porque eso se supone que es más rápido con un índice GiST. Ejemplo:
