AFAIK the only way to access single memory database from multiple connections
is through shared cache.
2018-05-15 0:27 GMT+02:00, Keith Medcalf <kmedc...@dessus.com>:
>>2018-05-13 12:50 GMT+02:00, Techno Magos :
>>> I do not have clear examples to post on this but would like to
>>> report findings around multi threaded read access (single process) in a
>>> large system that uses sqlite.
>>> This may be a known issue/restriction of memory sqlite behaviour,
>>> but wanted to check with the list first:
>>> 1. Running 2, 3, ... 6 multi threaded readers of a single *memory
>>> *sqlite database (via shared cache mode) on an 8 core cpu shows no
>>> throughput gain at all compared to single threaded throughput.
>>> In fact, it shows a throughput drop: i.e. if a single thread can
>>> do N simple queries/sec, 2 threads .. up to 6 threads do a little
>>> less (10% drop) in total. This suggests that access to memory
>>> sqlite can only be serialized?
> No one has asked the $10 million dollar question yet ... why are you doing
> this? It certainly does not sound like you have a highly constrained
> itty-bitty wee boxen for which the "shared cache" was designed (ie, you seem
> to have more that 4 cycles per second of CPU and 10 bytes of memory).
> So what was the configuration which you WERE PREVIOUSLY USING which was
> deficient and for which you are trying this optimization?
> Everyone knows that when you use "shared cache mode" you are trading off
> memory and CPU cycles against performance. Shared Cache Mode is designed so
> that if you are *really* so inclined you can run SQLite on your Tandy Pocket
> Computer too (https://en.wikipedia.org/wiki/Tandy_Pocket_Computer)
> The fact that there's a Highway to Hell but only a Stairway to Heaven says a
> lot about anticipated traffic volume.
> sqlite-users mailing list
sqlite-users mailing list