Proč to nefunguje
Typ indexu (tj. třída operátora) gin_trgm_ops je založen na % operátor, který funguje na dvou text argumenty:
CREATE OPERATOR trgm.%(
PROCEDURE = trgm.similarity_op,
LEFTARG = text,
RIGHTARG = text,
COMMUTATOR = %,
RESTRICT = contsel,
JOIN = contjoinsel);
Nemůžete použít gin_trgm_ops pro pole. Index definovaný pro sloupec pole nebude nikdy fungovat s any(array[...]) protože jednotlivé prvky polí nejsou indexovány. Indexování pole by vyžadovalo jiný typ indexu, konkrétně index pole gin.
Naštěstí index gin_trgm_ops byl navržen tak chytře, že pracuje s operátory ilike a ilike , které lze použít jako alternativní řešení (příklad je popsán níže).
Testovací tabulka
má dva sloupce (id serial primary key, names text[]) a obsahuje 100 000 latinských vět rozdělených do prvků pole.
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}
Hledání fragmentu slova praesent dává 7051 řádků za 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
Materializované zobrazení
Jedním z řešení je normalizace modelu, zahrnující vytvoření nové tabulky s jediným názvem v jednom řádku. Taková restrukturalizace může být obtížně implementovatelná a někdy nemožná kvůli existujícím dotazům, pohledům, funkcím nebo jiným závislostem. Podobného efektu lze dosáhnout bez změny struktury tabulky pomocí materializovaného pohledu.
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 není nutné, ale může být užitečné při agregaci jmen ve stejném pořadí jako v hlavní tabulce. Dotazování test_names poskytuje stejné výsledky jako hlavní tabulka ve stejnou dobu.
Po vytvoření indexu se doba provádění opakovaně zkracuje:
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
Řešení má několik nevýhod. Protože je pohled materializovaný, data jsou v databázi uložena dvakrát. Po změnách v hlavní tabulce je třeba zobrazení obnovit. A dotazy mohou být komplikovanější kvůli nutnosti připojit pohled k hlavní tabulce.
Pomocí ilike
Můžeme použít ilike na polích reprezentovaných jako text. K vytvoření indexu na poli jako celku potřebujeme neměnnou funkci:
create function text(text[])
returns text language sql immutable as
$$ select $1::text $$
create index on test using gin (text(names) gin_trgm_ops);
a použijte funkci v dotazech:
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 versus 2400 ms, celkem pěkný výsledek bez nutnosti vytváření dalších vztahů.
Toto řešení se zdá jednodušší a vyžaduje méně práce, ovšem za předpokladu, že ilike , což je méně přesný nástroj než trgm % operátora, je dostačující.
Proč bychom měli používat ilike spíše než % pro celá pole jako text?Podobnost závisí do značné míry na délce textů.Je velmi obtížné zvolit vhodný limit pro hledání slova v dlouhých textech různé délky.Např. s limit = 0.3 máme výsledky:
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)