2014-09-08 14:05 GMT-03:00 Flavio Henrique Araque Gurgel <[email protected]>:
>>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.
>
Aguardando a versão 9.4 com a pg_prewarm [1].... :-)
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).
+1.
Ainda não foi (ou eu perdi?) as informações do hardware (principalmente
memória disponível) e qual SO. Colocar shared_buffers para todo o tamanho
do banco não é o problema. O problema é não deixar espaço na RAM para o SO
realizar o seu cache.
O PostgreSQL depende muito do cache de SO, tanto que devemos configurar o
effective_cache_size corretamente também.
> Achei sua pergunta sobre ferramentas externas um pouco agressiva para o
> momento e isso não ajuda nada.
>
>
Bem. De certa forma o OP tem razão, o Solr tem ganhado do PostgreSQL em
termos de performance. Mas tudo promete ser diferente com a versão 9.4 e as
melhorias nos índices GIN [2][3]. Por isso acho que vale a pena "aguentar"
um pouco mais...
> 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
>
e o Sistema Operacional? Hardware?
> 2) O EXPLAIN ANALYZE da consulta, nos dois momentos, em que ela é boa e
> que ela é ruim (na sua visão).
Nesse caso acho melhor mesmo usar `EXPLAIN (ANALYZE, VERBOSE, BUFFERS)`
(dependendo da versão), assim podemos analisar melhor o efeito de cache do
PostgreSQL.
[1] http://www.postgresql.org/docs/9.4/static/pgprewarm.html
[2]
https://wiki.postgresql.org/images/2/25/Full-text_search_in_PostgreSQL_in_milliseconds-extended-version.pdf
[3] http://www.pgcon.org/2014/schedule/events/698.en.html
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
