> That's fair, but I wouldn't call the extra i/o imposed by sqlite "very very > cheap" either - it doubles writes (once to the rollback journal, once to > the DB), forces syncs, and likely results in a more seek heavy i/o pattern > (this depends a bit on schema design and whether the app requires/fully > takes advantage of relational operations).
Use explicit transaction maybe? 2018-05-14 6:15 GMT+02:00, Rowan Worth : > On 14 May 2018 at 01:08, Richard Damon wrote: > >> On 5/13/18 12:55 PM, Rowan Worth wrote: >> > On 9 May 2018 at 08:56, Richard Hipp wrote: >> > >> >> But with >> >> SQLite, there is no round-trip latency. A "round-trip" to and >> >> database is just a function call, and is very very cheap. >> >> >> > I want to emphasise that Dr. Hipp's usage of "round-trip" only includes >> the >> > latency of _communication_ between the app and database in this >> statement, >> > and excludes any processing time required by the database. >> > >> > If you were to interpret "round-trip" from an app-centric perspective >> > (as >> > in "the time taken to retrieve/commit data") then the statement becomes >> > misleading because handling the data involves i/o, possibly even >> > synchronous i/o, which is not "very very cheap" by any standard I'm >> > aware >> > of :) >> > >> > -Rowan >> > Yes, if the request requires I/O, then that costs time, but then the >> operation would likely use similar I/O in whatever way the application >> needed to get that information, so that I/O shouldn't really be charged >> to the use of a database, but to the information requested. One thing to >> remember is SQLite is often compared as a better way to get information >> then using simple disk i/o, so the 'cost' of using SQLite (compared to >> the alternative) shouldn't include the base time to read the file, but >> only any extra i/o above that. >> > > That's fair, but I wouldn't call the extra i/o imposed by sqlite "very very > cheap" either - it doubles writes (once to the rollback journal, once to > the DB), forces syncs, and likely results in a more seek heavy i/o pattern > (this depends a bit on schema design and whether the app requires/fully > takes advantage of relational operations). > > To be clear, this is not a criticism of sqlite. These costs are paid for a > reason (eg. durability) and I think sqlite does its job very efficiently. > You're also right that an app implementing similar features without sqlite > will have to pay similar costs. > > My point is simply that it's unwise to think of any DB query as having "no > latency" even when dealing with an sqlite DB. > -Rowan > _______________________________________________ > 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
