One reason why delete is slower than insert might be that delete has more potential for conflicts (concurrent transactions that read or update the same data). This cannot happen with inserts (unless transaction isolation concurrent read is used).
We don't know how exactly you do the deletes one by one, but one possible improvement would be to switch off autoCommit and do a commit only every n records. The better alternative might be to reduce the number of delete statements so the db can access rows more optimally. HTH Kind regards robert Michael Jÿrgens <[EMAIL PROTECTED]> schrieb am 27.06.05 16:51:21: > > One more question about that. > If it is not possible to empower the DELETE operation, is there a way to > reduce the priorisation for that? > I have the problem, that bacause of the high cpu load all other > operations slow down. > > regards, > > Michael > > Michael Jürgens schrieb: > > > Hi, > > I´m currently trying to delete 2 Mio rows from a database of 10 mio rows. > > Unfortunaly I have to do that one per one from a J2EE application. > > The performance of that is very bad (aprox. 13000 rows / hour) with 50 > > % cpu load on the database machine (2 x xeon 3,6 Ghz). > > Because of the high cpu load I don´t think it ist a client or caching > > problem. > > > > Why is delete so slow? > > > > Insertions (50000 / hour) in the same table have only 25% cpu load. > > > > Whatr can I do to enforce it? > > > > regards, > > > > Michael > > > > > > > -- > MaxDB Discussion Mailing List > For list archives: http://lists.mysql.com/maxdb > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > _________________________________________________________________________ Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179 -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
