I apologize that I am currently unable to reproduce the problem. The files I have just tested at home (same schema as the one I had in the office this week) behave as expected (i.e. no difference with or without transaction). I will try again in the office next week. If I can find the database with which I observed this issue, I will send it to you.
----- Original Message ----- From: Dan Kennedy <danielk1...@gmail.com> To: sqlite-users@mailinglists.sqlite.org <sqlite-users@mailinglists.sqlite.org> Sent: Friday, March 29, 2019, 19:33:51 Subject: [sqlite] Row locking sqlite3 On 28/3/62 01:04, Thomas Kurz wrote: >> I wonder whether SQLite is treating each DELETE as a single transaction. >> Could you try wrapping the main delete in BEGIN ... END and see whether that >> speeds up the cascaded DELETE ? Would you be able to find timings (either >> in your code or in the command-line tool) and tell us whether it's the >> DELETE or the END which takes the time ? > Ok, well.... very interesting and I'd never have had this idea, but indeed it > works: within a transaction, it takes only a few seconds. This is very > surprising as to me, a single DELETE statement is nothing more than that: a > single atomic operation which should automatically be treated as a > transaction (auto-commit-mode). > *confused* Me too. For the BEGIN/COMMIT version, you're counting the time spent in COMMIT as well, correct? If this is repeatable, we'd be very interesting in figuring out what is going on. Dan. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
