Bruno
Como esse servidor tem "razoavel" memória, acredito que o Otimizador do
SGBD ache mais barato resolver a query em memória do que utilizar índice.
Outro fato que acredito nisso, é que a memória é maior que a maior tabela
(16gb).
Se fosse no Oracle, iria te falar para por um HINT para forçar o Otimizador
a utilizar o índice, mas no postgresql nao sei se aceita Hints. Outra coisa
que poderia fazer é filtrar primeiro os predicados mais restritivos através
de alias de tabela +- como abaixo, assim na hora da junção teria menos
dados para fazer os Hash Join ou Nested Loop:
SELECT *
FROM C1,
( SELECT * FROM C2 WHERE FILTRO = QUALQUER ) C2A
WHERE
....
Em 1 de agosto de 2014 19:21, Bruno Silva <[email protected]> escreveu:
> Boa noite, estou fazendo análise de uma consulta e ela está extremamente
> lenta. Não consigo entender o motivo.
> Fazendo alguns testes vi que precisava de alguns índices e os criei, porém
> o Postgres não está utilizando eles.
> Esse [1] é o resultado do analyze da consulta[2] já com os índices criados.
> Já atualizei as estatísticas e nada.
> Os parâmetros dessa máquina são:
> work_mem=2GB
> shared_buffers=3GB
> effective_cache_size=16GB
> temp_buffers=1GB
>
> A máquina tem 96GB de RAM, é um Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, com
> 24 cores e tem tablespace separadas pros índices e a maior tabela (
> movimentacao - 16GB ) está em outro tablespace também.
>
> [1] http://explain.depesz.com/s/fAjE
> [2] http://pastebin.com/rJVUBVp0
>
>
> Bruno E. A. Silva.
> Analista de Sistemas.
>
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
