Juliano, obrigado pela resposta.
O que estou achando estranho é que quando rodamos o vacuum via pg_admin
(vacuum full ...), sem vacuumdb, nenhum erro acontece.
A principio imaginei que poderia ser algum bug no vacuumdb, mas usei-o para
fazer vaccum em outras bases no mesmo servidor e tudo ocorre
2013/6/14 Miguel Bezerra
> Prezados,
>
> Durante a execução do vacuum full via vacuumdb (vacuumdb -d locadora01
> -f), na versão 9.1.3, ocorre o erro de "ERROR: missing chunk number 0 for
> toast value 31115602 in pg_toast_2619".
>
> Isso se trata de um bug ou de base corrompida?
>
>
>
Base corr
Prezados,
Durante a execução do vacuum full via vacuumdb (vacuumdb -d locadora01 -f),
na versão 9.1.3, ocorre o erro de "ERROR: missing chunk number 0 for toast
value 31115602 in pg_toast_2619".
Isso se trata de um bug ou de base corrompida?
Parte do log, com os erros:
2013-06-14 10:24:23 BRT
Nem sempre indices compostos são a melhor alternativa, criar índices
individuais pode ser melhor quando realizado um SELECT, mas vai com calma,
quanto mais índices a tabela possuir mais tempo será preciso para INSERT e
UPDATE.
Em 14 de junho de 2013 15:43, Euler Taveira escreveu:
> On 14-06-201
On 14-06-2013 13:45, Douglas Fabiano Specht wrote:
> a PK por default é clusterizada,
>
PK clusterizada? Tabelas podem ser agrupadas de acordo com uma ordem
(aka "clusterizadas"); índices tem a sua ordem natural.
Você não pode garantir que tabelas permaneçam agrupadas por padrão por
causa do MVCC
Para relatórios que precisem apenas do campo ID_EMPRESA, crie um índice apenas
sobre este campo. A mesma recomendação se aplica aos relatórios com consulta
sobre o campo ID_VENDA.
Cordialmente,
Cláudio Leopoldino
postgresqlbr.blogspot.com/
=
A ordem do campo na tabela não tem nada a ver com a ordem do campo no
indice não né? Ou seria melhor ter na mesma ordem?
Estou modelando um banco aqui e se houver problemas já vou vasculhar o que
já tem pronto para conferir.
Em 14 de junho de 2013 13:45, Douglas Fabiano Specht <
douglasfabi...@
Em 14 de junho de 2013 13:31, Alessandro Gonçalves escreveu:
> Olá Fábio.
>
> Sim existe sim, isso ajuda na filtragem.
>
> Existe uma ordem onde é analisado os campos da esquerda para direita.
>
>
> Em 14 de junho de 2013 13:27, Fábio Thomaz escreveu:
>
>> Olá pessoal!
>>
>>Gostaria de saber d
Então talvez seria mais interessante eu sempre primeiramente ter o
ID_EMPRESA neste caso né? Já que em alguns relatórios eu irei filtrar
apenas por este campo alguns outros dependendo da situação.
Em 14 de junho de 2013 13:31, Alessandro Gonçalves escreveu:
> Olá Fábio.
>
> Sim existe sim, isso
Olá Fábio.
Sim existe sim, isso ajuda na filtragem.
Existe uma ordem onde é analisado os campos da esquerda para direita.
Em 14 de junho de 2013 13:27, Fábio Thomaz escreveu:
> Olá pessoal!
>
>Gostaria de saber dos expert's em BD se existe alguma diferença em usar
> primeiro um campo ou ou
Olá pessoal!
Gostaria de saber dos expert's em BD se existe alguma diferença em usar
primeiro um campo ou outro em uma chave primária composta.
Ex:
Tabela: Vendas
PK: ID_EMPRESA, ID_VENDA ou ID_VENDA, ID_EMPRESA
Isto faz alguma diferença? Sei que faz diferença quando uso uma consulta
SQL c
On 14-06-2013 10:35, Antonio Abner Junior wrote:
> Criei uma tabela e quando realizo a importação com o comando COPY, tudo
> ocorre sem erros no entanto não importa nada ! Alguém ja passou por isso ?
>
Cadê o mais importante (o erro)?
--
Euler Taveira Timbira - http://www.t
Em 14 de junho de 2013 10:35, Antonio Abner Junior <
antonio.abne...@gmail.com> escreveu:
> Olá Srs e Srtas !
>
> Estou com uma situação que nunca havia ocorrido antes !
> Estou querendo importar os logs do postgresql para uma tabela, com isso
> fiz as alterações necessárias no postgresql.conf par
Olá Srs e Srtas !
Estou com uma situação que nunca havia ocorrido antes !
Estou querendo importar os logs do postgresql para uma tabela, com isso fiz
as alterações necessárias no postgresql.conf para salvar em um arquivo
csv, reiniciei o serviço, verifiquei os logs gerados e tudo ok !
Criei uma t
14 matches
Mail list logo
