Olá, Fábio Acabei de ler o artigo, muito bom!
Abraços Em 29/11/07, Fabio Telles <[EMAIL PROTECTED]> escreveu: > > 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 > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
