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/ -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
signature.asc
Description: OpenPGP digital signature
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
