Je ne pense pas pouvoir l'expliquer mieux que le manuel ne le fait déjà :
Lors du choix du type d'index à utiliser, GiST ou GIN, tenez compte de ces différences de performances :
Les recherches d'index GIN sont environ trois fois plus rapides que GiST
Les index GIN prennent environ trois fois plus de temps à construire que GiST
Les index GIN sont modérément plus lents à mettre à jour que les index GiST, mais environ 10 fois plus lents si la prise en charge de la mise à jour rapide a été désactivée [...]
Les index GIN sont deux à trois fois plus grands que les index GiST
Le lien et la citation renvoient au manuel de Postgres 9.4. Les estimations de taille et de performances semblaient déjà légèrement dépassées. Avec Postgres 9.4, les chances ont considérablement changé en faveur de GIN .
Les notes de version de Postgres 9.4 incluent :
Réduire la taille de l'index GIN (Alexander Korotkov, Heikki Linnakangas) [...]
Améliorer la vitesse des recherches GIN multi-clés (Alexander Korotkov, HeikkiLinnakangas)
Les estimations de taille et de performances ont depuis été supprimées du manuel.
Notez qu'il existe des cas d'utilisation particuliers qui nécessitent l'un ou l'autre.
Une chose que vous avez mal comprise :vous jamais obtenir de mauvais résultats avec un index GiST. L'index fonctionne sur des valeurs de hachage, qui peuvent conduire à des faux positifs dans l'indice. Cela ne devrait devenir pertinent qu'avec un très grand nombre de mots différents dans vos documents. Les faux positifs sont éliminés après avoir revérifié la ligne réelle dans tous les cas. Le manuel :
Un index GiST est avec perte, ce qui signifie que l'index peut produire de fausses correspondances, et il est nécessaire de vérifier la ligne réelle de la table pour éliminer ces fausses correspondances. (PostgreSQL le fait automatiquement en cas de besoin. )
J'insiste sur moi.
