Li essa resposta, mas preciso perguntar. Se tiver trigger ou Foreign Key? O truncate não vai servir, aí então só mesmo o delete?
----- Original Message ----- From: "Fabio Telles" <[EMAIL PROTECTED]> To: "Comunidade PostgreSQL Brasileira" <[email protected]> Sent: Thursday, November 29, 2007 5:28 AM Subject: Re: [pgbr-geral] DELETE LENTO 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] _______________________________________________ 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
