Em 21 de fevereiro de 2014 12:55, Flavio Henrique Araque Gurgel < [email protected]> escreveu:
> > > Em 21-02-2014 16:48, Danilo Silva escreveu: > > >> 1º Deletar registros mais antigos, algo em torno de 10 milhões de >> registros; >> 2º Particionar a tabela; >> >> Penso em utilizar a 2ª opção visto ter acesso aos dados sem precisar >> modificar a aplicação (que é para ambiente web). >> >> Para a 2º opção o que vocês recomendam? Sei dos procedimentos para >> particionar tabelas (criar as tabelas filhas, criar as triggers, etc), >> mas a minha dúvida está na questão que a tabela já tem dados, como >> proceder neste caso, visto que a tabela não é pequena? >> > > > > Sobre os dados antigos, se você adotar uma coluna data como > particionadora, você pode justamente colocar a tabela antiga como filha do > particionamento, e removê-la quando não precisar mais dela. > Neste caso eu tenho que criar uma tabela que será a pai, e tabela atual, que virará filha eu apenas faço um ALTER TABLE, alterando o nome da tabela e colocando ela como INHERITS da nova tabela pai? Tenho algumas views que se utilizam dessa tabela, como ficará, pois se alterar o nome, automaticamente será alterado o nome nas views, terei que dar um drop/create nas views? > Cuidado com o particionamento: ele pode ajudar e também atrapalhar. > Verifique se seus SELECTs e UPDATEs tocarão mais que uma partição depois > que o particionamento ocorrer. Se isto for verdadeiro, cabe um estudo pra > ver se o custo dos SELECTs e UPDATEs não vai aumentar ao invés de diminuir. > > Enfim, pese tudo antes de sair fazendo, pra realmente ter um ganho. > Realmente cabe um estudo de performance, pois a chave do particionamento será com base em um campo data. []s Danilo
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
