2016-05-23 2:11 GMT-03:00 Lucas Possamai <[email protected]>: > > *Nova query: (O clientid está diferente apenas por motivos de WARM data)* > >> SELECT DISTINCT title >> FROM public.ja_jobs WHERE lower(title) LIKE lower('RYAN >> SHOWER') >> AND clientid = 31239 >> AND time_job > 1457826264 >> order BY title >> limit 10; > > > *Index:* > >> CREATE INDEX CONCURRENTLY ON public.ja_jobs (clientid, lower(title) >> varchar_pattern_ops, time_job); > > > > Desse modo está funcionando perfeitamente bem. E a query, de quase 3 > segundos passou à ser executada em 300ms. >
Mas nesse caso você perdeu o comportamento de wildcard não ? Estava lendo a thread e tive um cenário muito parecido com o seu, porém no meu caso precisava que o wildcard funcionasse. Tentei várias abordagens. Índices BTREE não conseguem fazer a pesquisa com wildcard all. Índices gin/gist com pg_trgm apesar de parecerem com bom custo no explain, se mostraram extremamente lentas e pesadas. (Acho até que o planejador se enganou mesmo atualizando as estatisticas). Então decidi testar as funções de full text search. Não estava muito esperançoso mas fiquei impressionado. Criei um índice baseado na função to_tsvector na coluna e realizei a pesquisa usando o tsquery. Ficou muito rápido e leve. Então ajustamos a aplicação que usava isso e está rodando que é uma beleza.
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
