On 1/21/19 4:38 PM, James K. Lowden wrote: > On Sun, 20 Jan 2019 17:01:25 -0700 > "Keith Medcalf" <kmedc...@dessus.com> wrote: > >> SQLite3 however has latencies on the order of microseconds > Is that really true? Are there machines for which SQLite's throughput > can be measured in transactions per millisecond? > > I think you're referring to the latency of the function-call overhead, > as opposed to using a network interface. But since DBMSs are basically > I/O machines, and the most interesting operations involve I/O, it's not > clear to me why function-call overhead is a relevant measure. > >> [SQLite] does not have the same opportunity for opportunistic >> behaviour as does a client/server database which may be serving >> thousands of concurrent (but different) applications. > That I think is the relevant measure. It's the number of clients, not > latency, that makes SQLite's lock-the-whole database feasible. On a > large machine supporting thousands of clients, the latency advantage > would be overwhelmed by the concurrency disadvantage, depending of > course on the rate of updates. > > --jkl
SQLite is NOT intended to be used over a network, and in fact there are warnings about accessing the database file over a network file system, as this often doesn't support the assumed locking primitives. SQLite is intended to be accessed over the local file system. Some operations can be order of microseconds if the data resides in cache, slightly longer if the database is in flash memory, and perhaps 100s of microseconds to milliseconds if the database is on spinning rust, and the operation needs to access the drive to get the needed data. -- Richard Damon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
