Também me interessei sobre o assunto: Existe algum problema de fazer o sequinte processo:
Aumentar maintenance_work_mem; Fazer repetidas vezes: update test set (coluna bytea)=null where pk in (select pk from test where (coluna bytea) is not null limit 1000); vacuum verbose test(coluna bytea) (vacuum parcial não dá lock) Quando terminar o processo: Fazer um: vacuum full verbose test(coluna bytea) (vacuum gera lock) 2017-04-27 18:20 GMT-03:00 Patrick B <patrickbake...@gmail.com>: > > > Em 28 de abril de 2017 06:00, Fabrízio de Royes Mello < > fabri...@timbira.com.br> escreveu: > >> >> >> Em 27 de abril de 2017 03:55, Flavio Henrique Araque Gurgel < >> fha...@gmail.com> 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/ >> >> >> > Interessante o pg_repack - Não conhecia! > > O problema do 'CREATE TABLE foo AS ...' é que não tenho tudo migrado > ainda.. está sendo aos poucos.... devo ter 40% da tabela migrada. O que > dificulta em criar a nova tabela pois *NULL as campobytea FROM bar *irá > por todas as rows com o campobytea = null. > > Eu tenho uma coluna migrado boolean. Talvez eu pudesse utilizar uma WHERE > migrado = true junto... O que acham? > > Patrick. > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
