SQLite does this too (I'm not sure about the "sort rowid" bit, but it would 
seem reasonable); and similarly for an update, it will first SELECT the 
affected rows in their result form and insert them all later.

-----Ursprüngliche Nachricht-----
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von Dinu
Gesendet: Sonntag, 17. Dezember 2017 23:13
An: sqlite-users@mailinglists.sqlite.org
Betreff: [EXTERNAL] Re: [sqlite] Atomic DELETE index optimisation?

By "one time only", I mean in my understanding, the way most DBs do on a DELETE 
is this: cache the ROWIDs while deleting data rows from the main and from the 
indexes, then when all ROWIDS are explored, sort the ROWID stream, and prune 
the trees from a sorted stream. This is both highly efficient (just like 
inserts, deletes of already ordered records are very efficient) and highly 
parallelizable.



--
Sent from: http://sqlite.1065341.n5.nabble.com/
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___________________________________________
 Gunter Hick | Software Engineer | Scientific Games International GmbH | 
Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 
1 80100 - 0

May be privileged. May be confidential. Please delete if not the addressee.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to