PostgreSQL heeft verschillende soorten indexen:B-tree, Hash, GiST, Gin en SP-GiST. Het is duidelijk dat elk van hen een specifieke behoefte dekt. De PostgreSQL-documentatie zegt bijvoorbeeld over GIN-indexen:
Dus GIN-indexen kunnen worden gebruikt om de elementen van een array, een hstore enzovoort te indexeren.
Maar deze keer zullen we het hebben over een van die contrib-modules die meer soorten operators biedt die kunnen worden gebruikt met GIN-indexen:pg_trgm.
Deze module maakt trigrammen van tekstreeksen zodat deze kan worden gebruikt om overeenkomsten te vinden. Hierdoor kunnen GIN-achtige indexen die de operatorklasse gin_trgm_ops gebruiken, worden gebruikt in LIKE-zoekopdrachten, zelfs wanneer het jokerteken '%' wordt gevonden aan het begin van het zoekpatroon (bijvoorbeeld:LIKE-naam '%jaime%').
Om een index te maken die op deze manier kan worden gebruikt, moet de index als volgt worden gemaakt:
CREATE INDEX idx_gin ON table USING GIN (campo_texto gin_trgm_ops);
Met een index als deze heb ik zoekopdrachten zien dalen van meer dan 10 seconden tot enkele milliseconden; voordat u zich echter haast om deze indexen te maken, laten we eens kijken naar de problemen die u heeft.
Overweeg de volgende vraag "select show_trgm('Jaime Casanova');" Dit toont ons de trigrammen van een tekststring, in dit geval 15 trigrammen. Het is dus niet moeilijk voor te stellen dat dit type index veel groeit, en hoe groter de tekststrings, hoe meer de index groeit (omdat er meer trigrammen zullen zijn). Een andere voor de hand liggende conclusie is dat het onderhouden van dit type indexen duur kan zijn, in feite kunnen ze de prestaties van INSERT en UPDATE enorm beïnvloeden, vooral als er meerdere van deze indexen in dezelfde tabel staan, om dit probleem een beetje te verminderen een techniek genaamd fastupdate werd uitgevonden die bestaat uit het bijhouden van een ongeordende lijst van hangende. Dus de INSERT en UPDATE in plaats van in te voegen in de hoofdindex, doen ze dit in deze aanvullende structuur totdat een VACUUM optreedt of totdat de lijst in behandeling groter wordt dan work_mem. De nadelen zijn:1) het lezen van de index moet ook deze aanvullende structuur lezen, wat de queryprestaties kan beïnvloeden; en 2) een INSERT of UPDATE kan ervoor zorgen dat de achterstand te groot wordt en zal daarom de achterstand gaan verwerken, wat gevolgen heeft voor die INSERT of UPDATE en alle andere bewerkingen die gelijktijdig op die tafel plaatsvinden.
Tot slot; een GIN-index samen met de pg_trgm-module kan de prestaties van sommige zoekopdrachten enorm helpen, maar ze mogen niet worden misbruikt omdat ze een tweesnijdend zwaard kunnen zijn.