On 5/14/18, 9:17 AM, "sqlite-users on behalf of Bernard Ertl" <sqlite-users-boun...@mailinglists.sqlite.org on behalf of bern...@interplansystems.com> wrote:
Apologies if I muddled the waters here. I read the "SQLightning" response below as SQLitening. I didn't know there was a similarly named project out there. I also can't see the beginning of this discussion to have context on what was originally asked, so I don't know which project was actually intended. Ah, OK. Here's more context, don't know if it'll help: http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2018-May/079224.html Clemens Ladisch wrote: > Techno Magos wrote: >> So, memory sqlite is not really usable with multiple threads (readers). >> While one might expect that multiple readers of *memory *content could >> scale even better than with file content. > > Concurrent accesses to the same in-memory data structures must be > serialized. In shared-cache mode, the connections share the cache, while > on-disk connections each have their own cache. > >> Is there some special mode possible to achieve scaling up throughput with >> multiple threads for memory sqlite content? > > Put a DB file on a RAM disk. Or on a normal disk (with looser synchronous > and journal_mode settings), and rely on the OS file cache. Or just use SQLightning, which has no scalability limits for readers. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users