Hum... me empolguei um pouco e resolvi escrever sobre o assunto no meu blog. É claro que se trata de um caso particular de DELETE, mas fica a dica:
http://www.midstorm.org/~telles/2007/11/29/nao-use-delete-use-insert/ []s Em 29/11/07, Fabio Telles<[EMAIL PROTECTED]> escreveu: > Em 28/11/07, Brasil Software<[EMAIL PROTECTED]> escreveu: > > Pessoal ! > > Estou com um grande problema, migrei minha base do firebird para > > postgresql e quando estou deletando um registro o tempo > > chega a ser vergonhoso em relação ao firebird. > > > > Alguem pode me ajudar. > > minha base tem: > > 293 tabelas > > algumas com 2 milhões de registros. > > > > Se você tem que deletar muitos registros a melhor coisa a fazer para > acelerar a operação é utilizar um TRUNCATE. Se você vai excluir poucos > registros, um índice para pesquisar o campo de seleção da cláusula > WHERE deve resolver. > > Ao excluir muitos registros, o DELETE é proibitivo. Você tem três > alternativas interessantes: > > 1) Executar o TRUNCATE e pronto. Isso funciona somente se você quer > excluir TODOS registros da tabela. Nem sempre é o caso! > > 2) Particionar a tabela e depois dar um TRUNCATE apenas na partição > que lhe interessa. Esta é com certeza uma excelente opção para bases > grandes onde você consegue prever uma exclusão de rotina em um grupo > previsível de dados, como "os registros do último trimestre". > Particionar tabelas grandes tem uma série de outros benefícios > colaterais que melhoram substancialmente o desempenho e diminuem o > gasto com os discos. > > 3) Se você não consegue prever o ponto de corte para excluir seus > dados, impedindo-o de particionar sua tabela de forma adequada, há um > último recurso que é utilizar o INSERT no lugar do DELETE: > - Mova os dados que NÃO serão excluÍdos para outra tabela auxiliar com > um CREATE TABLE AS SELECT (...) WHERE (...) > - Dê um TRUNCATE na tabela original. > - Carrege os dados na tabela original com um INSERT (...) SELECT (...) > - Dê um DROP TABLE na tabela auxiliar. > > Uma variação ainda mais rápida, mas mais delicada é você fazer a > tabela auxiliar se transformar em tabela original. Com isto, após > criar a tabela auxiliar, você precisa excluir a tabela original e > renomear a tabela auxiliar. O problema é que você terá depois que > recriar todos os CONSTRAINTS na mão. Em uma rotina bem planejada a > variante é mais rápida ainda. > > > Em ambientes realmente grandes eu vejo as pessoas aplicarem uma > combinação das técnicas 2 e 3. Quando se tem um volume que passa da > casa dos 500GB o particionamento é obrigatório. Quando o número de > linhas a excluir é grande, o DELETE nunca é eficiente, não apenas no > PostgreSQL, mas no Oracle e DB2 também... > > Espero ter ajudado. > > []s > Fábio Telles > -- > blog: http://www.midstorm.org/~telles/ > e-mail / jabber: [EMAIL PROTECTED] > -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
