2016-04-09 5:15 GMT+12:00 Fabrízio de Royes Mello <fabri...@timbira.com.br>:
> On 07-04-2016 23:29, drum.lu...@gmail.com wrote: > > > > > > 2016-04-08 14:25 GMT+12:00 Marcio A. Sepp <mar...@zyontecnologia.com.br > > <mailto:mar...@zyontecnologia.com.br>>: > > > > > >> > >> Não vai demorar.. pois não será feito tudo de uma vez.. será feito > >> 1000 rows por vez, por exemplo. > >> > >> > >> Apenas por curiosidade, dropar o campo levaria mais tempo? > > > > > > Apenas a coluna X deverá ser setada como NULL - Outras colunas da Row > > ainda serão utilizadas, tendo isso envista, não é possível deleta-la. > > > > Já passei por situação similar em um cenário 24x7 em uma tabela "muito" > acessada e que nao poderiamos indispor ela com um VACUUM FULL, entao o > que fizemos: > > 1) ajustamos algumas coisas no autovacuum desta tabela pra ele nao ficar > rodando toda hora por conta dos updates > > 2) UPDATES em porcoes da tabela (1000 registros por vez e a cada 10000 > vacuum manual) > > 3) Depois de todas linhas alteradas rodamos um pg_repack [1] que recria > toda ela com minimo de locks. > > 4) voltei confs originas do autovacuum para a tabela em questão > > Esse procedimento no meu cenário levou mais de semana, mas foi feito com > segurança e sem parar nada. > > Att, > > [1] http://reorg.github.io/pg_repack/ > > -- > > Obrigado pelo seu email Fabrízio! Estou realizando testes e acredito que, caso não seja autorizado a utilizar o VACCUM FULL, fazer os passos que você descreveu será bem provável. Obrigado! Lucas
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
