Por que isso não funciona
O tipo de índice (ou seja, classe de operador)
gin_trgm_ops é baseado em % operador, que funciona em dois text argumentos:CREATE OPERATOR trgm.%(
PROCEDURE = trgm.similarity_op,
LEFTARG = text,
RIGHTARG = text,
COMMUTATOR = %,
RESTRICT = contsel,
JOIN = contjoinsel);
Você não pode usar
gin_trgm_ops para arrays.Um índice definido para uma coluna de array nunca funcionará com any(array[...]) porque elementos individuais de arrays não são indexados. Indexar um array exigiria um tipo diferente de índice, ou seja, índice de array gin. Felizmente, o índice
gin_trgm_ops foi projetado de forma tão inteligente que está trabalhando com operadores like e ilike , que pode ser usado como uma solução alternativa (exemplo descrito abaixo). Tabela de teste
tem duas colunas
(id serial primary key, names text[]) e contém 100.000 frases latinas divididas em elementos de matriz. 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}
Procurando a palavra fragmento
praesent dá 7051 linhas em 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
Visão materializada
Uma solução é normalizar o modelo, envolvendo a criação de uma nova tabela com um único nome em uma linha. Essa reestruturação pode ser difícil de implementar e às vezes impossível devido a consultas, visualizações, funções ou outras dependências existentes. Um efeito semelhante pode ser alcançado sem alterar a estrutura da tabela, usando uma visão materializada.
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 não é necessário, mas pode ser útil ao agregar os nomes na mesma ordem da tabela principal. Consultando test_names dá os mesmos resultados que a tabela principal ao mesmo tempo. Depois de criar o índice, o tempo de execução diminui repetidamente:
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
A solução tem algumas desvantagens. Como a visão é materializada, os dados são armazenados duas vezes no banco de dados. Você precisa se lembrar de atualizar a visualização após as alterações na tabela principal. E as consultas podem ser mais complicadas devido à necessidade de unir a visão à tabela principal.
Usando ilike
Podemos usar
ilike nas matrizes representadas como texto. Precisamos de uma função imutável para criar o índice no array como um todo:create function text(text[])
returns text language sql immutable as
$$ select $1::text $$
create index on test using gin (text(names) gin_trgm_ops);
e use a função nas consultas:
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, resultado bastante bom sem a necessidade de criar relações adicionais.
Esta solução parece mais simples e requer menos trabalho, desde que
ilike , que é uma ferramenta menos precisa que o trgm % operador, é suficiente. Por que devemos usar
ilike em vez de % para matrizes inteiras como texto? A semelhança depende em grande parte do comprimento dos textos. É muito difícil escolher um limite apropriado para a pesquisa de uma palavra em textos longos de vários comprimentos. com limit = 0.3 temos os resultados: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)
