Jag tror inte att jag skulle kunna förklara det bättre än vad manualen redan gör:
När du väljer vilken indextyp du ska använda, GiST eller GIN, beakta dessa prestandaskillnader:
GIN-indexsökningar är ungefär tre gånger snabbare än GiST
GIN-index tar ungefär tre gånger längre tid att bygga än GiST
GIN-index är måttligt långsammare att uppdatera än GiST-index, men cirka 10 gånger långsammare om stödet för snabb uppdatering var inaktiverat [...]
GIN-index är två till tre gånger större än GiST-index
Länk och citat hänvisar till manualen för Postgres 9.4. Uppskattningar av storlek och prestanda verkade redan något föråldrade. Med Postgres 9.4 har oddsen förändrats avsevärt till förmån för GIN .
Releasenoterna för Postgres 9.4 inkluderar:
Minska GIN-indexstorleken (Alexander Korotkov, Heikki Linnakangas) [...]
Förbättra hastigheten på flernyckels GIN-uppslagningar (Alexander Korotkov, HeikkiLinnakangas)
Uppskattningar av storlek och prestanda har sedan tagits bort från manualen.
Observera att det finns speciella användningsfall som kräver det ena eller det andra.
En sak du missförstod:Du aldrig få fel resultat med ett GiST-index. Indexet arbetar på hash-värden, som kan leda till falska positiva resultat i indexet. Detta bör bara bli relevant med ett mycket stort antal olika ord i dina dokument. Falska positiva resultat elimineras i alla fall efter att ha kontrollerat den faktiska raden igen. Manualen:
Ett GiST-index är förlustbringande, vilket innebär att indexet kan producera falska matchningar, och det är nödvändigt att kontrollera den faktiska tabellraden för att eliminera sådana falska matchningar. (PostgreSQL gör detta automatiskt vid behov. )
Djärv betoning min.