On 5/14/18, 9:17 AM, "sqlite-users on behalf of Bernard Ertl"
<[email protected] on behalf of
[email protected]> 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
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
