O PostgreSQL possui vários tipos de índices:B-tree, Hash, GiST, Gin e SP-GiST. Obviamente, cada um deles cobre uma necessidade específica. Por exemplo, a documentação do PostgreSQL diz sobre índices GIN:
Assim, os índices GIN podem ser usados para indexar os elementos de um array, de um hstore e assim por diante.
Mas desta vez falaremos sobre um desses módulos contrib que fornecem mais tipos de operadores que podem ser usados com índices GIN:pg_trgm.
Este módulo cria trigramas de strings de texto para que possam ser usados para encontrar semelhanças. Isso permite que índices do tipo GIN que usam a classe de operadores gin_trgm_ops sejam usados em pesquisas LIKE mesmo quando o curinga '%' for encontrado no início do padrão de pesquisa (por exemplo:nome LIKE '%jaime%').
Para criar um índice que possa ser usado assim, o índice deve ser criado assim:
CREATE INDEX idx_gin ON table USING GIN (campo_texto gin_trgm_ops);
Com um índice como esse, vi as consultas caírem de mais de 10s para alguns milissegundos; no entanto, antes de se apressar para criar esses índices, vamos considerar os problemas que você tem.
Considere a seguinte consulta "select show_trgm('Jaime Casanova');" Isso nos mostra os trigramas de uma string de texto, neste caso 15 trigramas. Então não é difícil imaginar que esse tipo de índice cresce muito, e quanto maiores as strings de texto, mais o índice cresce (pois haverá mais trigramas). Outra conclusão óbvia é que manter esse tipo de índices pode ser caro, na verdade eles podem afetar muito o desempenho de INSERT e UPDATE, principalmente se houver vários desses índices na mesma tabela, para reduzir um pouco esse problema uma técnica chamada fastupdate foi inventado que consiste em manter uma lista não ordenada de pendências. Assim, INSERT e UPDATE em vez de inserir no índice principal, eles o fazem nessa estrutura adicional até que ocorra um VACUUM ou até que a lista pendente fique maior que work_mem. As desvantagens são:1) a leitura do índice também deve ler essa estrutura adicional, o que pode afetar o desempenho da consulta; e 2) um INSERT ou UPDATE pode fazer com que o backlog cresça muito e, portanto, iniciará o processamento do backlog que afetará esse INSERT ou UPDATE e todas as outras operações que ocorrem simultaneamente nessa tabela.
Em conclusão; um índice GIN junto com o módulo pg_trgm pode ajudar bastante no desempenho de algumas consultas, porém não deve ser abusado, pois pode ser uma faca de dois gumes.