>>Você tem índices aí?
>>Você tem outras tabelas?
>>Enfim, seu teste me parece mais uma rota de colisão com uma parede do que
um teste. É muito simples e não corresponde ao uso real de um banco de
dados.
Tenho índices para a chave estrangeira e para o tsvector que é o filtro da
consulta.
Tenho um outra tabela pequena (1141 registros, 168kB)
>>Índices também ocupam espaço do cache. Índices GIN costumam ser grandes.
o índice GIN do tsvector é de 644MB
a tabela principal é de 1822MB
totalizando 2466MB, que é 98,8% de toda a base de dados
>>Quem vai pro cache do PostgreSQL são páginas, eventualmente uma tabela
inteira,
apenas os registros resultado dos filtros da consulta que vão para o cache?
>>.lembrando que há o cache do S.O. a considerar.
por se tratar de uma única tabela(98,8% de toda a base de dados), e alto
processamento nos filtros (text search), pensei que a melhor saída seria
colocar todo o banco no cache,
e gostaria de usar recursos próprio do postgres, ou será que para alta
performance será necessário utilizar ferramentas como solr?
Segue SQL utilizado para testes:
select a.tipo, a.inicio, a.texto, b.nome as bairro, ts_rank(texto_search,
query) as rank
from anuncio as a inner join bairro as b on b.codigo = a.codigo_bairro
, to_tsquery('pt', 'cozinha') as query
where texto_search @@ query
order by rank desc, b.nome
limit 20 offset 0
Meu desafio é agilizar esta consulta, pois sempre que altero o texto da
consulta, demora cerca de 50 segundos
mas das próximas vezes demora 0,5 segundo (em cache)
Atenciosamente,
Alessandro Lima
email [email protected]
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
