2016-12-12 14:56 GMT-02:00 Cleiton Luiz Domazak <cleitondoma...@gmail.com>:
> > > 2016-12-12 14:04 GMT-02:00 Tiago José Adami <adam...@gmail.com>: > >> Em 12 de dezembro de 2016 11:45, Cleiton Luiz Domazak >> <cleitondoma...@gmail.com> escreveu: >> > (corte) >> > Alguém já passou por essa situação? >> > > >> Eu já: com o PostgreSQL 9.4 (não lembro se era 9.4.2 ou 9.4.3). Nas >> últimas releases, por exemplo a 9.4.8 que uso no ambiente de testes >> (com mesmo SO), o problema não ocorre. >> >> No meu caso havia uma tabela PUBLIC.RESERVA com um atributo chamado >> "DATA" tipo DATE. >> > > Meu caso é mais misterioso, pq se eu aumento o meu range de data, funciona > super rapido, quando deveria ser ao contrário :) > >> >> Como o servidor (hardware) é fraquinho eu me antecipei e criei vários >> índices parciais por ano contendo a cláusula "WHERE DATA BETWEEN >> 'YYYY-01-01' AND 'YYYY-12-31'" (substituindo YYYY pelos anos de 2014 >> até 2020). A cláusula between do ano era usada em todas as consultas >> envolvendo o atributo DATA. >> >> Adicionalmente a estes índices anuais ainda existia um índice composto >> com o atributo DATA, sendo ele o primeiro da lista de atributos do >> índice. >> >> Sofri um tempão para descobrir o problema. Como é utilizado um >> servidor Debian e o PostgreSQL dos repositórios oficiais a atualização >> dos binários demorou um pouco para sair, então tive que encontrar a >> solução "na mão", que foi excluir os índices parciais deixando apenas >> um índice "normal" utilizando o atributo "DATA". >> >> Sendo assim: >> >> 1) Certifique-se de estar utilizando a última release da versão 9.4; >> > O servidor está na 9.4.9 e infelizmente não tenho como atualizar ele nos próximos dias. > > Vou atualizar para a ultima release. > >> >> 2) Verifique se existem índices parciais sobre este atributo de data; >> > Nem index tinha, criei e ele não é utilizado. > >> 3) Teste em outro ambiente com o mesmo SO se o problema ocorre após >> importar um arquivo de DUMP; >> >> 3.1) Caso no ambiente de testes funcione, você pode cogitar a >> possibilidade de fazer um DUMP completo, apagar o banco de dados, >> criar um novo e reimportar o DUMP no mesmo servidor. Se houver algo >> corrompido isto deve resolver; >> > > Já pedi para o cliente um dump para eu fazer um teste de restore, pq estou > achando que seja realmente alguma coisa que possa ser resolvida com um > dump/restore > >> >> 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 > >> Adami >> > > Vlw Adami, muito obrigado. Vou realizar esses testes e volto a > compartilhar com vocês o que tive que resultados. > >> _______________________________________________ >> 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
