Utilizei o comando abaixo em uma tabela para testar:
alter table log.cidade_log cluster on cidade_log_pkey;
cluster log.cidade_log
e fiz alguns testes, aparentemente sempre que realizo um delete o tamanho
da tabela já diminui automaticamente,
não é necessário executar o cluster log.cidade_log
On 03-12-2012 09:54, Alessandro Lima wrote:
e fiz alguns testes, aparentemente sempre que realizo um delete o tamanho da
tabela já diminui automaticamente,
não é necessário executar o cluster log.cidade_log sempre que exlcluir um
grande numero de registros?
Uma vez executado o CLUSTER, não
On 30-11-2012 23:44, Fabrízio de Royes Mello wrote:
Em 30 de novembro de 2012 19:34, Euler Taveira eu...@timbira.com
mailto:eu...@timbira.com escreveu:
[...]
Desaconselho o uso do VF em favor do autovacuum + VACUUM manual (se
necessário).
Nem a nova implementação do VF
Criei uma tabela de log que é populada via trigger, mas ela está ficando
muito grande, cerca de 7GB, exclui quase todos os registros desta tabela,
deixando apenas os mais recentes, mas a tabela continua com o mesmo tamanho.
Obs.: Meu postgres é o 8.4 e estou utilizando o pgadmin para visualizar
Em 30 de novembro de 2012 11:50, Alessandro Lima
grandegoia...@gmail.comescreveu:
Criei uma tabela de log que é populada via trigger, mas ela está ficando
muito grande, cerca de 7GB, exclui quase todos os registros desta tabela,
deixando apenas os mais recentes, mas a tabela continua com o
Em 30-11-2012 11:50, Alessandro Lima escreveu:
Criei uma tabela de log que é populada via trigger, mas ela está ficando
muito grande, cerca de 7GB, exclui quase todos os registros desta
tabela, deixando apenas os mais recentes, mas a tabela continua com o
mesmo tamanho.
Então você usou
Olá,
Em 30 de novembro de 2012 11:50, Alessandro Lima
grandegoia...@gmail.comescreveu:
Criei uma tabela de log que é populada via trigger, mas ela está ficando
muito grande, cerca de 7GB, exclui quase todos os registros desta tabela,
deixando apenas os mais recentes, mas a tabela continua com
Em 30-11-2012 11:58, JotaComm escreveu:
O que devo fazer para diminuir o tamanho desta tabela?
O vacuum não vai liberar o espaço a no SO, por isso sua tabela mantem o
mesmo tamanho e cada vez cresce mais. O Analyze apenas atualiza as
estatísiticas. Para liberar espaço você pode usar o
Em 30 de novembro de 2012 12:03, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
2) Pra manter esse banco com facilidade, particionar essa tabela de log
é vantajoso com certeza.
Neste caso, o procedimento de particionamento com a tabela já populada
seria o mesmo criando as
Em 30-11-2012 13:26, Danilo Silva escreveu:
2) Pra manter esse banco com facilidade, particionar essa tabela de log
é vantajoso com certeza.
Neste caso, o procedimento de particionamento com a tabela já populada
seria o mesmo criando as tabelas do zero? Pois o meu conhecimento sobre
Em 30 de novembro de 2012 13:28, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Em 30-11-2012 13:26, Danilo Silva escreveu:
2) Pra manter esse banco com facilidade, particionar essa tabela de
log
é vantajoso com certeza.
Neste caso, o procedimento de
On 30-11-2012 13:38, Alessandro Lima wrote:
Agora surgiu outra dúvida, se eu excluir apenas os valores de algumas colunas
(colunas grandes como text), o vacuum full também diminuiria o tamnanho da
tabela?
Pode ser que sim. Tudo vai depender do quão grande são os seus campos. Vide a
Em 30 de novembro de 2012 19:34, Euler Taveira eu...@timbira.com escreveu:
[...]
Desaconselho o uso do VF em favor do autovacuum + VACUUM manual (se
necessário).
Nem a nova implementação do VF é recomendada, claro que se tiver *janela de
manutenção* para tal atividade ???
Att,
--
Alessandro,
Minha sugestão é clusterizar a tabela com o primary key dela, é a metodo
mais atual de se liberar espaço fisico após grandes deleções de registros.
Uma boa opção seria um upgrade do seu SGDB, assim você vai ter sempre os
metodos mais atuais.
Abraços,
Em 30 de novembro de 2012
14 matches
Mail list logo
