It's not clear to me why reads must be serialized at all. Maybe this could
be re-thought? Maybe there should be a way to tell SQLite that a certain
DB or table is to be read-only and unserialized?
On Sun, May 13, 2018 at 7:15 AM, Keith Medcalf <kmedc...@dessus.com> wrote:
> Say Hi to Gene!
> So I believe what you are saying is something like this: If I take a
> child and have it count as fast as it can then it can count to X in an
> hour. However, I take the same child but have it count as fast as it can
> at five minute stretches, the sum of the X's is less than it was at one
> go. If I get the child to do this at random intervals consuming juice
> boxes in between, the sum of the X's is even lower, the higher the number
> of interruptions becomes.
> In the second case the task consists of counting to ten and then drinking
> a juice box. If you get one child, then it takes time X. Interestingly,
> if you get two children, the tasks (empty juice boxes) stack up twice as
> fast. There is some overlap between the operations. As you add more and
> more children it goes faster and faster, but not quite. Eventally all the
> children are drinking the juice box as the same time and adding more
> children does not make things go faster.
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
> >-----Original Message-----
> >From: sqlite-users [mailto:sqlite-users-
> >boun...@mailinglists.sqlite.org] On Behalf Of Techno Magos
> >Sent: Sunday, 13 May, 2018 04:51
> >To: firstname.lastname@example.org
> >Subject: [sqlite] Multi threaded readers on memory sqlite cannot
> >I do not have clear examples to post on this but would like to
> >findings around multi threaded read access (single process) in a
> >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
> >database (via shared cache mode) on an 8 core cpu shows no throughput
> >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,
> >threads .. up to 6 threads do a little less (10% drop) in total. This
> >suggests that access to memory sqlite can only be serialized?
> >2. Running the same example on sqlite *file *(multi threaded mode;
> >journal) scales almost linearly; so 6 threads provide nearly 6xN
> >throughput. Single threaded throughput is a bit slower (around 15-
> >than single threaded in-memory access (expected).
> >So, memory sqlite is not really usable with multiple threads
> >While one might expect that multiple readers of *memory *content
> >scale even better than with file content.
> >Can this restriction be lifted?
> >Is there some special mode possible to achieve scaling up throughput
> >multiple threads for memory sqlite content?
> >sqlite-users mailing list
> sqlite-users mailing list
Dictionary.com's word of the year: *complicit*
sqlite-users mailing list