Em 27 de abril de 2017 03:55, Flavio Henrique Araque Gurgel < [email protected]> escreveu: >> >> >> É um sistema online com 30 mil usuários, ou seja, não tem como eu ter downtime. Eu entendo que não há como fazer isso sem ter um downtime, pois qualquer coisa que eu faça eu irei precisar de um exclusive lock naquela tabela e, o usuário, não consegue nem logar se não tiver acesso à ela. >> >> Mas de qualquer forma eu provavelmente irei escolher a opção do pg_dump. Pois para eu fazer tanto o vacuum full quanto o CREATE TABLE AS, irei precisar ter mais espaço em disco e pra isso vou ter que por o sistema 2x offline, uma para incluir mais espaço e outra para rodar os comandos. >> >> A tabela tem 4TB, complicando ainda mais minha vida. > > > Sim, mas isso é contando sua coluna bytea que vai desaparecer. > Portanto, a solução de criar uma tabela como disse o Euler pode ser vantajosa, pois a nova tabela não terá o tamanho da original e será bem menor. > > Você pode fazer isso "a quente" e ter um corte de serviço bem rápido só pra inserir as novas linhas desde a criação e remover a antiga tabela gigante, o que provavelmente levará poucos minutos e, dependendo do sistema, poderá até trabalhar sem as linhas ausentes até que você as insira, ou seja, você pode fazer tudo com um downtime bem bem pequeno. >
Outra opção pra esse cenário seria rodar aquele UPDATE e após isso um pg_repack [1] para eliminar o inchaço *sem* o downtime de um vacuum full ou de algum script para recriar a tabela. 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
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
