Dlaczego to nie działa
Typ indeksu (np. klasa operatora) gin_trgm_ops opiera się na % operator, który działa na dwóch text argumenty:
CREATE OPERATOR trgm.%(
PROCEDURE = trgm.similarity_op,
LEFTARG = text,
RIGHTARG = text,
COMMUTATOR = %,
RESTRICT = contsel,
JOIN = contjoinsel);
Nie możesz użyć gin_trgm_ops for arrays. Indeks zdefiniowany dla kolumny tablicy nigdy nie będzie działał z any(array[...]) ponieważ poszczególne elementy tablic nie są indeksowane. Indeksowanie tablicy wymagałoby innego typu indeksu, a mianowicie indeksu tablicy gin.
Na szczęście indeks gin_trgm_ops został tak sprytnie zaprojektowany, że działa z operatorami like i ilike , które można wykorzystać jako alternatywne rozwiązanie (przykład opisany poniżej).
Tabela testowa
ma dwie kolumny (id serial primary key, names text[]) i zawiera 100000 zdań łacińskich podzielonych na elementy tablicy.
select count(*), sum(cardinality(names))::int words from test;
count | words
--------+---------
100000 | 1799389
select * from test limit 1;
id | names
----+---------------------------------------------------------------------------------------------------------------
1 | {fugiat,odio,aut,quis,dolorem,exercitationem,fugiat,voluptates,facere,error,debitis,ut,nam,et,voluptatem,eum}
Wyszukiwanie fragmentu słowa praesent daje 7051 wierszy w 2400 ms:
explain analyse
select count(*)
from test
where 'praesent' % any(names);
QUERY PLAN
---------------------------------------------------------------------------------------------------------------
Aggregate (cost=5479.49..5479.50 rows=1 width=0) (actual time=2400.866..2400.866 rows=1 loops=1)
-> Seq Scan on test (cost=0.00..5477.00 rows=996 width=0) (actual time=1.464..2400.271 rows=7051 loops=1)
Filter: ('praesent'::text % ANY (names))
Rows Removed by Filter: 92949
Planning time: 1.038 ms
Execution time: 2400.916 ms
Widok zmaterializowany
Jednym z rozwiązań jest normalizacja modelu, polegająca na utworzeniu nowej tabeli z jedną nazwą w jednym wierszu. Taka restrukturyzacja może być trudna do wdrożenia, a czasami niemożliwa z powodu istniejących zapytań, widoków, funkcji lub innych zależności. Podobny efekt można osiągnąć bez zmiany struktury tabeli, używając zmaterializowanego widoku.
create materialized view test_names as
select id, name, name_id
from test
cross join unnest(names) with ordinality u(name, name_id)
with data;
With ordinality nie jest konieczne, ale może być przydatne podczas agregowania nazw w tej samej kolejności, co w tabeli głównej. Zapytania test_names daje takie same wyniki jak główna tabela w tym samym czasie.
Po utworzeniu indeksu czas wykonania spada wielokrotnie:
create index on test_names using gin (name gin_trgm_ops);
explain analyse
select count(distinct id)
from test_names
where 'praesent' % name
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=4888.89..4888.90 rows=1 width=4) (actual time=56.045..56.045 rows=1 loops=1)
-> Bitmap Heap Scan on test_names (cost=141.95..4884.39 rows=1799 width=4) (actual time=10.513..54.987 rows=7230 loops=1)
Recheck Cond: ('praesent'::text % name)
Rows Removed by Index Recheck: 7219
Heap Blocks: exact=8122
-> Bitmap Index Scan on test_names_name_idx (cost=0.00..141.50 rows=1799 width=0) (actual time=9.512..9.512 rows=14449 loops=1)
Index Cond: ('praesent'::text % name)
Planning time: 2.990 ms
Execution time: 56.521 ms
Rozwiązanie ma kilka wad. Ponieważ widok jest zmaterializowany, dane są przechowywane w bazie danych dwukrotnie. Trzeba pamiętać o odświeżeniu widoku po zmianach w tabeli głównej. Zapytania mogą być bardziej skomplikowane ze względu na konieczność łączenia widoku z tabelą główną.
Korzystanie z ilike
Możemy użyć ilike na tablicach reprezentowanych jako tekst. Potrzebujemy niezmiennej funkcji, aby utworzyć indeks w tablicy jako całości:
create function text(text[])
returns text language sql immutable as
$$ select $1::text $$
create index on test using gin (text(names) gin_trgm_ops);
i użyj funkcji w zapytaniach:
explain analyse
select count(*)
from test
where text(names) ilike '%praesent%'
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=117.06..117.07 rows=1 width=0) (actual time=60.585..60.585 rows=1 loops=1)
-> Bitmap Heap Scan on test (cost=76.08..117.03 rows=10 width=0) (actual time=2.560..60.161 rows=7051 loops=1)
Recheck Cond: (text(names) ~~* '%praesent%'::text)
Heap Blocks: exact=2899
-> Bitmap Index Scan on test_text_idx (cost=0.00..76.08 rows=10 width=0) (actual time=2.160..2.160 rows=7051 loops=1)
Index Cond: (text(names) ~~* '%praesent%'::text)
Planning time: 3.301 ms
Execution time: 60.876 ms
60 kontra 2400 ms, całkiem niezły wynik bez konieczności tworzenia dodatkowych relacji.
To rozwiązanie wydaje się prostsze i wymaga mniej pracy, pod warunkiem jednak, że ilike , który jest mniej precyzyjnym narzędziem niż trgm % operatora, wystarczy.
Dlaczego powinniśmy używać ilike zamiast % dla całych tablic jako tekstu? Podobieństwo zależy w dużej mierze od długości tekstów. Bardzo trudno jest wybrać odpowiedni limit wyszukiwania słowa w długich tekstach o różnej długości. z limit = 0.3 mamy wyniki:
with data(txt) as (
values
('praesentium,distinctio,modi,nulla,commodi,tempore'),
('praesentium,distinctio,modi,nulla,commodi'),
('praesentium,distinctio,modi,nulla'),
('praesentium,distinctio,modi'),
('praesentium,distinctio'),
('praesentium')
)
select length(txt), similarity('praesent', txt), 'praesent' % txt "matched?"
from data;
length | similarity | matched?
--------+------------+----------
49 | 0.166667 | f <--!
41 | 0.2 | f <--!
33 | 0.228571 | f <--!
27 | 0.275862 | f <--!
22 | 0.333333 | t
11 | 0.615385 | t
(6 rows)
