PostgreSQL har flera typer av index:B-tree, Hash, GiST, Gin och SP-GiST. Uppenbarligen täcker var och en av dem ett specifikt behov. Till exempel säger PostgreSQL-dokumentationen om GIN-index:
Så GIN-index kan användas för att indexera elementen i en array, en hstore och så vidare.
Men den här gången kommer vi att prata om en av dessa bidragsmoduler som tillhandahåller fler typer av operatorer som kan användas med GIN-index:pg_trgm.
Den här modulen skapar trigram av textsträngar så att den kan användas för att hitta likheter. Detta gör att GIN-liknande index som använder operatorklassen gin_trgm_ops kan användas i LIKE-sökningar även när jokertecknet '%' hittas i början av sökmönstret (till exempel:LIKE-namn '%jaime%').
För att skapa ett index som kan användas så här måste indexet skapas så här:
CREATE INDEX idx_gin ON table USING GIN (campo_texto gin_trgm_ops);
Med ett index som detta har jag sett frågor sjunka från över 10s till några millisekunder; Men innan du skyndar dig att skapa dessa index, låt oss överväga vilka problem du har.
Tänk på följande fråga "select show_trgm('Jaime Casanova');" Detta visar oss trigramen för en textsträng, i det här fallet 15 trigram. Så det är inte svårt att föreställa sig att den här typen av index växer mycket, och ju större textsträngar desto mer växer indexet (eftersom det blir fler trigram). En annan uppenbar slutsats är att det kan vara dyrt att underhålla den här typen av index, i själva verket kan de påverka prestandan för INSERT och UPDATE i hög grad, speciellt om det finns flera av dessa index på samma bord, för att minska detta problem lite en teknik som kallas fastupdate uppfanns som består av att upprätthålla en oordnad lista över väntande. Så INSERT och UPDATE istället för att infogas i huvudindexet, gör de det i denna extra struktur tills ett VAKUUM uppstår eller tills den väntande listan blir större än work_mem. Nackdelarna är:1) att läsa indexet måste också läsa denna extra struktur, vilket kan påverka frågeprestanda; och 2) en INSERT eller UPPDATERING kan göra att eftersläpningen blir för stor och kommer därför att börja bearbeta eftersläpningen, vilket kommer att påverka den INSERT eller UPPDATERING och alla andra operationer som sker samtidigt på den tabellen.
Sammanfattningsvis; ett GIN-index tillsammans med pg_trgm-modulen kan i hög grad hjälpa prestanda för vissa frågor, men de bör inte missbrukas eftersom de kan vara ett tveeggat svärd.