Depois de receber algumas orientações perspicazes em um post anterior aqui, vou rodar VACUUM FULLem 4 tabelas PostgreSQL 9.3.10. Os tamanhos das mesas são:
1) links_publicreply: ~30 milhões de linhas, 9 colunas, 3 índices (tipos: int, timestamp, char, bool)
2) links_reply: ~25 milhões de linhas, 8 colunas, 6 índices (tipos: int, text, timestamp, char)
3) links_link: ~8 milhões de linhas, 14 colunas, 3 índices (tipos: int, text, dbl precision, timestamp, char bool)
4) links_user_sessions: ~2 milhões de linhas, 7 colunas, 4 índices (tipos: int, text, timestamp, inet)
Esta é minha primeira tentativa de recuperar espaço em disco. É um servidor ocupado de um site de rede social local. Nenhum tempo é realmente "tempo de inatividade". Mas o menos ocupado é ~4:00 AM, então a janela que vou usar.
Falando por experiência, vocês podem formar alguma opinião sobre quanto tempo VACUUM FULL levaria para as 4 mesas que indiquei? Eu gostaria de colocar uma mensagem "em manutenção até xx:xx:xx" no site enquanto isso está acontecendo. Eu sei que ninguém pode ter certeza, mas isso é determinista o suficiente para você formar uma opinião aproximada?
Em segundo lugar, apenas para estarmos na mesma página, os comandos que eu estaria executando no psql são simplesmente VACUUM (FULL, VERBOSE, ANALYZE) link_publicreply;(e assim por diante), corretos? Não queira estragar tudo.
Então
VACUUM FULL, vai ser um problema, pois leva um bloqueio exclusivo em cada tabela que processa. Considere a ferramenta da comunidadepg_repackque consegue o mesmo sem bloqueios exclusivos.Relacionado:
Nada disso afeta o tamanho dos backups, já que eles não incluem linhas mortas para começar.