Em 15 de dezembro de 2016 09:26, Cleiton Luiz Domazak <[email protected]> escreveu: >> Rodou um VACUUM ANALYZE sobre a tabela após criar o índice? Qual a >> definição (comando) que você usou para criar o índice? > > Foi a primeira coisa a ser feita, fiz VACUUM, VACUUM FULL, ANALYZE, REINDEX, > o pacote completo kkkk. > > O indice foi criado apenas em cima do campo data, sem nenhum tipo de > formatação ou filtro.
Ok. Isto deveria ter causando algum efeito. >> > Fiz o restore do dump gerado pelo cliente, e o mesmo problema ocorre no >> > meu ambiente de testes. E ocorre em situações um pouco aleatórias. >> > >> > Essas são as datas que eu usei e se funcionou ou não. Muito esquisito. >> > >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-10-01' OK >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-01' OK >> > AND DR.DTINSERT>='2016-09-30' AND DR.DTINSERT<='2016-11-01' OK >> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-30' OK >> > AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-30' OK >> > AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-01' NOK >> >> Qual a quantidade de registros total na tabela e a média mensal? > > Se você observar, se aumentar o range de data, a query fica rápida. >> >> Primeiro execute um VACUUM ANALYZE sobre a tabela como mencionei antes >> e depois roda um EXPLAIN para vermos o que o plano de acesso está >> fazendo para pelo menos uma consulta que ficou OK e para a NOK. > > Consegui finalmente rodar o EXPLAIN ANALYZE, e o plano realmente muda, agora > vou ver o que mudou e pq. Desculpe, por um momento esqueci que o EXPLAIN não concluía. De acordo com as suas informações, se a tabela não possui nenhuma peculiaridade, há grandes chances de ser algum bug no PostgreSQL. Antes de analisar o resultado do EXPLAIN, que tal tentar o seguinte: 1) Alterar o predicado da consulta para AND DR.DTINSERT BETWEEN '2016-10-30' AND '2016-11-01'. Por gentileza informe se houve algum resultado positivo ou negativo. 2) Instalar mesma versão 9.4.9 em uma outra máquina (talvez uma máquina virtual?) com SO compatível ao seu ambiente de produção (Windows ou Linux ou Unix) e importar o dump (pode ser apenas a tabela em questão) para tentar reproduzir o erro; 3) Se o erro persistir, atualize o PostgreSQL para a versão 9.4.10 e refaça o teste; 4) Se o erro persistir, instale então a versão 9.5.5 e depois a versão 9.6.1, importe novamente dump e refaça o teste para as duas versões; Em qualquer momento, se o problema não ocorrer mais, saberemos que já existe uma versão já com esta anomalia corrigida - então sugiro proceder com a atualização. Caso nenhuma das alternativas apresente uma solução é muito importante coletar o máximo de informações, descrever todas as etapas já realizadas nos testes e submeter o erro para a lista oficial de bugs [1] (em inglês, claro) seguindo as recomendações [2]. [1] mailto:[email protected] [2] https://www.postgresql.org/docs/9.4/static/bug-reporting.html Adami _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
