On Wed, Mar 27, 2019 at 1:02 PM Simon Slavin <slav...@bigfraud.org> wrote:
> On 27 Mar 2019, at 11:48am, Thomas Kurz <sqlite.2...@t-net.ruhr> wrote: > Locking by rows is a slow operation. You first have to lock the entire > database, then lock the row, then release the database. And each of those > locks is a test-and-lock operation. Also, because of the way indexes work, > locking a row often locks that row's neighbours too in each index. Code > which just locks the entire database is simpler and faster. > It's not so much about performance Simon, although that remains a concerns of course, it's about *concurrency*. Yes it adds overhead compared to simpler and less granular locking, but you gain better concurrency in exchange. Just like single threaded typically achieves better per-thread throughput than multi-threaded. But when you have many users or many threads, you typically do not want them sitting idle while only a single one at a time is busy. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
