Já passei por problemas de executar muitos comandos dentro de uma mesma
transação, mas era em situações de atualização automatizada de clientes a 1
~ 2 anos sem receber atualização de sistema. Devido a grande quantidade de
registros que existiam na base de dados era impossível realizar uma
Em 27 de março de 2012 17:25, Marcelo Silva (IG) marc...@ig.com.br
escreveu:
Pessoal, tentei fazer com umas subquerys mas não deu certo, a forma que
consegui foi a mais convencional possível, mas estou achando bem tosca, tem
uma maneira de melhorar esse select?
Você pode somar a data e hora
Consegui resolver com sua dica, obrigado.
Fui fazendo vacuum em cada tabela do sistema independentemente e localizei
algumas tabelas temporárias que estavam dando o erro.
Fazendo um delete from pg_class where relname = 'nome_table'consegui
fazer o vacuum na base inteira.
Meu servidor é:
Quando vou fazer vacuum na base da o erro abaixo, nesta base estão
acontecendo algumas coisas estranhas que acredito que venha a ser por este
problema.
Gostaria de saber o que o pessoal faz quando se depara com isto, na
internet não se acha muita coisa.
ERRO: catalog is missing 3 attribute(s)
O autovacuum está habilitado? Experimente fazer um VACUUM ANALYZE
tb_produto_loja e depois teste os dois plano novamente. Se a diferença dos
números de rows *não* se aproximar, apresente os planos novamente.
O autovaccum estava desabilitado, fiz o VACUUM FULL ANALYZE em toda base e
um REINDEX
Só por curiosidade, qual a diferença do de tempo de execução do SQL
original com o compilado (com os casts) agora, depois do VACUUM?
Agora depois do vacuum ficou instantâneo os 2 sql's, segue ae os 2 planos
de execução depois do vacuum.
Em termos de tempo, os sqls sem cast eram praticamente
Não sabia que CASTS deixava querys mais lentas. No máximo a diferença é
imperceptível, ou estou errado?
Nesse SQL abaixo fez muita diferença o cast
Cadê os planos de execução com a visão e sem ela provando o ocorrido?
Infelizmente não tenho salvo a melhor situação pra representar este caso,
Boa tarde,
meu problema é o seguinte, depois de compilar uma view toda identada e
organizada certinha, o postgre desorganiza todo o fonte, coloca um monte de
cast desnecessário e a performance diminui.
Trabalho atualmente com o PG 9.1 e já sofri algumas vezes por conta disso,
tive uma situação
Eu não consegui fazer backup de um servidor 9.1, a versão que eu tinha
instalada aqui era alpha, não sei se tinha algum bug nisto.
Mas tente utilizar o dump do 9.1 pra fazer o backu, utilize o parâmetro
-i (ou --ignore-version) na linha de comando do dump.
Minha solução aqui, foi extrair os
Configuração no arquivo postgresql.conf
procure a config datestyle e altere seu valor para iso, dmy
Em 7 de novembro de 2011 14:15, Marcus Túlio Ramos
marcustuliora...@gmail.com escreveu:
Amigos, estou encontrando o seguinte erro:
ERROR: 22008: date/time field value out of range: 28/02/2011
Depois de mudar o arquivo, tem q mandar o servidor recarregar as
configurações ou intão mande reiniciar o servidor
Em 7 de novembro de 2011 16:51, Marcus Túlio Ramos
marcustuliora...@gmail.com escreveu:
AMIGOS, NÃO FUNCIONOU... mas creio que este não seja o problema, pois no
meu banco
Não funcionou ainda.
Apaguei todas as libpq que haviam no computador, deixei somente ao do
postgre 8.4 (Que é a versão do servidor), e o mesmo erro continua.
Também tenho todas as DLL's da pasta bin do postgre 8.4 em uma pasta
separada lá no cliente e o erro também ocorre executando desta pasta a
Quando vou fazer um backup de uma base de dados, ocorre o seguinte erro:
pg_dump: Cópia do conteúdo da tabela tb_entrada falhou: PQgetCopyData()
falhou.
pg_dump: Mensagem de erro do servidor: servidor fechou a conexão
inesperadamente
Isto provavelmente significa que o servidor terminou de
13 matches
Mail list logo
