Indeks GIN PostgreSQL wolniejszy niż GIST dla pg_trgm?

Niektóre problemy wyróżniają się:

Najpierw rozważ uaktualnienie do bieżącej wersji Postgresa . W chwili pisania tego tekstu jest to pg 9.6 lub pg 10 (obecnie beta). Od wersji Pg 9.4 wprowadzono wiele ulepszeń dla indeksów GIN, dodatkowego modułu pg_trgm i ogólnie dużych zbiorów danych.

Następnie potrzebujesz znacznie więcej RAM , w szczególności wyższy work_mem ustawienie. Widzę z tego wiersza w EXPLAIN wyjście:

Heap Blocks: exact=7625 lossy=223807

"stratny" w szczegółach Skanowania stosu mapy bitowej (z Twoimi konkretnymi liczbami) wskazuje na dramatyczny niedobór work_mem . Postgres zbiera tylko adresy bloków w skanowaniu indeksu mapy bitowej zamiast wskaźników wierszy, ponieważ oczekuje się, że będzie to szybsze z niskim work_mem ustawienie (nie może przechowywać dokładnych adresów w pamięci RAM). O wiele więcej niekwalifikujących się wierszy musi zostać przefiltrowanych w następującym Skanowaniu sterty bitmapy tą drogą. Ta powiązana odpowiedź zawiera szczegóły:

• Wiersz „Ponownie sprawdź Cond:” w planach zapytań ze skanowaniem indeksu bitmapy

Ale nie ustawiaj work_mem też wysoko bez uwzględnienia całej sytuacji:

• Optymalizuj proste zapytanie przy użyciu daty i tekstu ORDER BY

Mogą wystąpić inne problemy, takie jak przerost indeksu lub tabeli lub więcej wąskich gardeł w konfiguracji. Ale jeśli naprawisz tylko te dwa elementy, zapytanie powinno być dużo już szybciej.

Ponadto, czy naprawdę musisz pobrać wszystkie 40k wierszy w przykładzie? Prawdopodobnie chcesz dodać mały LIMIT do zapytania i przeprowadź wyszukiwanie „najbliższego sąsiada” – w takim przypadku indeks GiST jest mimo wszystko lepszym wyborem, ponieważ to ma być szybszy z indeksem GiST. Przykład:

• Najlepszy indeks funkcji podobieństwa