Em 29/11/07, sergio<[EMAIL PROTECTED]> escreveu: > 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? >
Em QUALQUER operação de carga, seja UPDATE, INSERT ou DELETE, você deveria desabilitar todos constraints, triggers, índices, etc. Só depois de concluída a transação você habilita/recria tudo novamente. Se você não faz isso (não apenas no PostgreSQL, mas em qualquer SGDB) o seu desempenho é muito ruim. Vide comentários no artigo. Atenciosamente, Fábio Telles > > ----- Original Message ----- > From: "Fabio Telles" <[EMAIL PROTECTED]> > To: "Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.org.br> > 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 > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- 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
