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 >> > > Não, o PostgreSQL não aceita hints e nunca aceitará. É um erro achar que > hints são uma solução para esse tipo de problemas, normalmente eles causam > mais problemas do que resolvem. Nem sempre usar um índice é o melhor > caminho para uma consulta e isso varia com o volume das tabelas envolvidas.
Flavio, Discordo sobre Hints, pois imagine a situação abaixo: torce_para count(*) -------------- ---------- São Paulo 4.000.000 Corinthians 8.000.000 Palmeiras 6.000.000 Santos 2.000.000 VOCEM de Assis 8 Se existe um índice em torce_para e uma query pedir todos os torcedores do VOCEM de Assis, é muito provável que o PostgreSQL fará "Sequencial Scan" (full table scan - Oracle). É muito mais barato para o Otimizador fazer um Sequencial Scan que um acesso a milhões de linhas do índice. Se voce tiver a possibilidade de inserir um Hint poderia resolver a query muito mais rápido, forçando o uso do indice, pois sao somente 8 registros. Outra opção seria criar um Histograma. Outro motivo que se utiliza Hint é para configurar grau de paralelismo em queries, mas no PostgreSQL até a versão 8 eu sei que não tem isso implementado. Alguém sabe se o PostgreSQL atual trabalha com paralelismo? > 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 >> .... >> > > Você olhou a consulta do colega antes de dizer isso? > Não, acabei nao observando o Link para a Query! > 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 >> > > Aqui está o effective_cache_size que o outro colega não viu (afinal com > top posting é difícil mesmo separar tudo). > > temp_buffers=1GB >> > > Muito. Diminua isso. Não faz sentido e só ocupa espaço do seu > shared_buffers. Uns 8MB tá de bom tamanho. > > > >> 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 >> > > A parte mais cara da sua consulta, de acordo com o explain, é: > > WHERE (movjulg.bolcancelado IS FALSE > AND movjulg.dtamovimento <= '2013-12-31 23:59:59-03') > > Poderia verificar se existem índices nessas colunas? caso haja, a > distribuição estatística dos dados nelas pode afetar o plano também. > Mostre-nos mais detalhes, por favor, dessa tabela e essas colunas. > > []s > Flavio Gurgel > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > []`s Wiliam
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
