Algumas questões se destacam:
Primeiro, considere atualizar para uma versão atual do Postgres . No momento em que escrevo, é página 9.6 ou página 10 (atualmente beta). Desde a Pg 9.4 houve várias melhorias para índices GIN, o módulo adicional pg_trgm e big data em geral.
Em seguida, você precisa de muito mais RAM , em particular um
work_mem mais alto contexto. Eu posso dizer a partir desta linha no EXPLAIN resultado:Heap Blocks: exact=7625 lossy=223807
"com perdas" nos detalhes de um Bitmap Heap Scan (com seus números específicos) indica uma escassez dramática de
work_mem . O Postgres só coleta endereços de bloco na varredura de índice de bitmap em vez de ponteiros de linha porque espera-se que seja mais rápido com seu work_mem baixo configuração (não pode armazenar endereços exatos na RAM). Muitas outras linhas não qualificadas precisam ser filtradas no seguinte Bitmap Heap Scan Por aqui. Esta resposta relacionada tem detalhes:Mas não defina
work_mem também alta sem considerar toda a situação:Pode haver outros problemas, como aumento de índice ou tabela ou mais gargalos de configuração. Mas se você corrigir apenas esses dois itens, a consulta deve ser muito mais rápido já.
Além disso, você realmente precisa recuperar todas as 40 mil linhas no exemplo? Você provavelmente deseja adicionar um pequeno
LIMIT para a consulta e torná-la uma pesquisa de "vizinho mais próximo" - nesse caso, um índice GiST é a melhor escolha, porque isso é suposto ser mais rápido com um índice GiST. Exemplo:
