Certains problèmes ressortent :
Tout d'abord, envisagez de passer à une version actuelle de Postgres . Au moment de la rédaction, c'est pg 9.6 ou pg 10 (actuellement bêta). Depuis Pg 9.4, plusieurs améliorations ont été apportées aux index GIN, au module supplémentaire pg_trgm et au Big Data en général.
Ensuite, vous avez besoin de beaucoup plus de RAM , en particulier un work_mem plus élevé paramètre. Je peux dire à partir de cette ligne dans le EXPLAIN sortie :
Heap Blocks: exact=7625 lossy=223807
"avec perte" dans les détails d'une analyse de tas bitmap (avec vos numéros particuliers) indique une pénurie dramatique de work_mem . Postgres ne collecte que les adresses de bloc dans l'analyse de l'index bitmap au lieu des pointeurs de ligne, car cela devrait être plus rapide avec votre faible work_mem paramètre (ne peut pas contenir d'adresses exactes dans la RAM). De nombreuses autres lignes non éligibles doivent être filtrées dans le Bitmap Heap Scan suivant Par ici. Cette réponse connexe contient des détails :
Mais ne définissez pas work_mem aussi élevé sans considérer l'ensemble de la situation :
Il peut y avoir d'autres problèmes, comme un gonflement d'index ou de table ou d'autres goulots d'étranglement de configuration. Mais si vous corrigez uniquement ces deux éléments, la requête devrait être beaucoup déjà plus vite.
De plus, avez-vous vraiment besoin de récupérer toutes les lignes de 40 000 lignes dans l'exemple ? Vous souhaitez probablement ajouter un petit LIMIT à la requête et en faire une recherche "plus proche voisin" - auquel cas un index GiST est le meilleur choix après tout, car cela est censé être plus rapide avec un index GiST. Exemple :
