PostgreSQL ma kilka typów indeksów:B-drzewo, Hash, GiST, Gin i SP-GiST. Oczywiście każdy z nich obejmuje konkretną potrzebę. Na przykład dokumentacja PostgreSQL mówi o indeksach GIN:
Tak więc indeksy GIN mogą być używane do indeksowania elementów tablicy, hstore i tak dalej.
Ale tym razem porozmawiamy o jednym z tych modułów contrib, które zapewniają więcej rodzajów operatorów, których można używać z indeksami GIN:pg_trgm.
Ten moduł tworzy trygramy ciągów tekstowych, dzięki czemu można go używać do znajdowania podobieństw. Dzięki temu indeksy podobne do GIN, które używają klasy operatora gin_trgm_ops, mogą być używane w wyszukiwaniach LIKE, nawet jeśli symbol wieloznaczny „%” zostanie znaleziony na początku wzorca wyszukiwania (na przykład:nazwa LIKE „%jaime%”).
Aby utworzyć indeks, którego można używać w ten sposób, indeks musi być utworzony w następujący sposób:
CREATE INDEX idx_gin ON table USING GIN (campo_texto gin_trgm_ops);
Przy takim indeksie widziałem, jak zapytania spadają z ponad 10 sekund do kilku milisekund; jednak zanim zaczniesz spieszyć się z tworzeniem tych indeksów, zastanówmy się, jakie masz problemy.
Rozważ następujące zapytanie „select show_trgm('Jaime Casanova');” To pokazuje nam trygramy ciągu tekstowego, w tym przypadku 15 trygramów. Nietrudno więc sobie wyobrazić, że ten rodzaj indeksu bardzo rośnie, a im większe ciągi tekstowe, tym bardziej indeks rośnie (bo trygramów będzie więcej). Kolejnym oczywistym wnioskiem jest to, że utrzymanie tego typu indeksów może być kosztowne, w rzeczywistości mogą one znacznie wpłynąć na wydajność INSERT i UPDATE, zwłaszcza jeśli jest kilka takich indeksów na tej samej tabeli, aby nieco zmniejszyć ten problem techniką zwaną fastupdate został wynaleziony, co polega na utrzymywaniu nieuporządkowanej listy oczekujących. Tak więc INSERT i UPDATE zamiast wstawiać do głównego indeksu, robią to w tej dodatkowej strukturze, dopóki nie pojawi się VACUUM lub dopóki lista oczekujących nie stanie się większa niż work_mem. Wady to:1) odczyt indeksu musi również odczytać tę dodatkową strukturę, która może wpłynąć na wydajność zapytania; oraz 2) INSERT lub UPDATE może spowodować zbyt duży wzrost zaległości i w związku z tym rozpocznie przetwarzanie zaległości, co wpłynie na tę operację INSERT lub UPDATE i wszystkie inne operacje wykonywane jednocześnie na tej tabeli.
Podsumowując; indeks GIN wraz z modułem pg_trgm może znacznie pomóc w wydajności niektórych zapytań, jednak nie należy ich nadużywać, ponieważ mogą być mieczem obosiecznym.