On 08-09-2014 19:44, Alessandro Lima wrote:
>>> Achei sua pergunta sobre ferramentas externas um pouco agressiva para o
> momento e isso não ajuda nada.
> Não foi minha intenção ser agressivo, sou muito grato pelas ajudas e venho
> aprendendo bastante com essa lista,
> não tenho experiência com TEXT SEARCH, por isso toquei no assunto do solr,
> para saber qual a opnião de vocês.
>
>>> 1) Qual a versão do PostgreSQL
> 9.3.2
>
Atualize para 9.3.5.
>>> Ainda não foi (ou eu perdi?) as informações do hardware (principalmente
> memória disponível) e qual SO
>>> e o Sistema Operacional? Hardware?
> Windows 8.1 64 bits, intel i7 2,1Ghz, 8GB ram, hd sata (é apenas um
> ambiente de testes)
>
>>> O PostgreSQL depende muito do cache de SO, tanto que devemos configurar o
> effective_cache_size corretamente também.
> effective_cache_size 3584MB
> shared_buffers 3584MB
>
Você está usando quase metade da RAM para shared_buffers? Isso não é uma
boa prática. Além disso, valores altos do shared_buffers (> 2GB) mostram
uma degradação de performance no Windows; experimente 1 GB. Você tem
certeza que boa parte da RAM que seria usada para cache de arquivos não
está sendo usada por outros programas (monitore memória no gerenciador
de tarefas observando se há esgotamento da memória física disponível e
quanto de memória está sendo utilizada para cache do sistema)?
>>> Nesse caso acho melhor mesmo usar `EXPLAIN (ANALYZE, VERBOSE, BUFFERS)`
> (dependendo da versão), assim podemos analisar melhor o efeito de cache do
> PostgreSQL.
> Primeira consulta:
> "Limit (cost=27797.55..27797.60 rows=20 width=1161) (actual
> time=46109.061..46109.064 rows=20 loops=1)"
^^^^^^^^^^^^^^
Do tempo total acima...
> " -> Bitmap Heap Scan on public.anuncio a
> (cost=110.00..27339.99 rows=8000 width=1110) (actual
> time=91.682..43901.170 rows=58844 loops=1)"
^^^^^^^^^^^^^^^^^^^^^^^
... esse trecho está custando quase todo o tempo (em torno de 95%).
> " Output: a.id, a.id_usuario, a.codigo_bairro,
> a.tipo, a.texto, a.inicio, a.texto_search"
> " Recheck Cond: (a.texto_search @@ query.query)"
> " Buffers: shared hit=50811 read=2055"
^^^^^^^^^^^^^^^^^^
O que não justifica a leitura de 2055 páginas (~ 16MB) e ...
> " -> Bitmap Index Scan on idx_gin_texto_search
> (cost=0.00..108.00 rows=8000 width=0) (actual time=77.595..77.595
> rows=58844 loops=1)"
> " Index Cond: (a.texto_search @@
> query.query)"
> " Buffers: shared hit=3 read=45"
^^^^^^^^^^^^^^
... 45 páginas do índice (~ 360 kB).
Tem algo de muito estranho no seu ambiente. Além do que já foi pedido,
ajudaria bastante se tivesse apresentado a estrutura das tabelas e uma
descrição do que pretende com a consulta testada (eu simplesmente *não*
entendi a linha depois do inner join e o porquê do "offset 0" (favor
testar sem ele pois ele tem o efeito de não permitir algumas otimizações).
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
Qual é o número de registros na tabela anuncio?
Por fim, antes de apresentar qualquer EXPLAIN faça um ANALYZE em todas
as tabelas envolvidas. Notei que as estatísticas estão completamente
erradas (8000 x 58844). Você chegou a testar com um valor maior para
estatísticas, ou seja:
ALTER TABLE anuncio ALTER texto_search SET STATISTICS 500;
ANALYZE anuncio;
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
