2016-12-15 16:48 GMT-02:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:
> 2016-12-15 11:23 GMT-02:00 Tiago José Adami <adam...@gmail.com>: > >> Em 15 de dezembro de 2016 09:26, Cleiton Luiz Domazak >> <cleitondoma...@gmail.com> 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. >> > > Testei em um server com a ultima release 9.4.10 e o mesmo problema ocorre. > > >> >> 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. >> > > Já havia feito esse teste, mas como já fiz tanta coisa que já não lembrava > refiz kkkk, e o problema ainda assim ocorre. > >> >> 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; >> > > Como ocorreu o mesmo problema em outra vesão e outro server, acabei > eliminando essa possibilidade > >> >> 3) Se o erro persistir, atualize o PostgreSQL para a versão 9.4.10 e >> refaça o teste; >> > > Feito, e ocorre o mesmo erro. > >> >> 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; >> > > Vou fazer um teste na versão 9.6, no mesmo server de teste, tenho um > cluster da 9.6 no ar. > >> >> 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]. >> > > Esses são os EXPLAINs gerados na query completa. > > EXPLAIN NOK - https://explain.depesz.com/s/YRnJ > EXPLAIN OK - https://explain.depesz.com/s/dHqS > > O que observei é que na query NOK, ao invés de o plano realizar um MERGE > JOIN, ele fez vários NESTED LOOP e ai que o bixo pega. Lembrando que na > query que ocorre o problema o range de data e consequentemente a quantidade > de dados é menor. > Galera, problema resolvido, e da forma mais vergonhosa possível kkkkkkkk, era apenas um LEFT JOIN fora do lugar, como a query é gerada, tinha ficado um LEFT largado e acabava mudando o plano da query. > > >> [1] mailto:pgsql-b...@postgresql.org >> [2] https://www.postgresql.org/docs/9.4/static/bug-reporting.html >> >> Adami >> _______________________________________________ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
