>>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.
Tudo isso pode entrar ou não no que você está chamando de cache.
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
Ok, note que é um grande índice, 1/3 do tamanho da tabela.
>>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?
Vão para o cache as páginas lidas do disco. O tempo que elas ficam no
cache é ditado por um algoritmo de lru.
.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?
O cache do S.O. é muito importante. Para leitura, ele mais importante
que o cache do PostgreSQL (minha opinião e a de algumas outras pessoas).
Achei sua pergunta sobre ferramentas externas um pouco agressiva para o
momento e isso não ajuda nada.
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
Duas informações muito úteis para uma discussão saudável:
1) Qual a versão do PostgreSQL
2) O EXPLAIN ANALYZE da consulta, nos dois momentos, em que ela é boa e
que ela é ruim (na sua visão).
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)
Com as respostas acima pode ser que achemos onde está seu problema.
Note que *pode ser*, afinal existem várias outras variáveis a considerar.
[]s
Flavio GUrgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
