On Sun, Mar 19, 2006 at 06:40:51AM -0500, [EMAIL PROTECTED] wrote: > Tim Larson <[EMAIL PROTECTED]> wrote: > > I did not find anything that lets us do work specifically > > during the time spans when sqlite is waiting on the disk drive > > Most of the disk drive wait time is spent inside the fsync() > or FlushFileBuffers() system calls. There is no way to have > the same thread be doing other work while these system calls > are running. > -- > D. Richard Hipp <[EMAIL PROTECTED]>
That makes sense for writes, due to the sqlite and OS caches, but are those also the main disk drive wait times for reads? I was under the impression that for reads that using either a multi-process and/or a multi-threaded design could give a performance enhancement, due to the way this allows the OS to schedule reads. What I am trying to find out is if this is the case and if there is a way with sqlite to get this benefit (increased performance by having more than one "select" being processed at a time) without having to leave the single threaded, single process design. For context, I am thinking about using sqlite in combination the pseudo-threaded software at http://www.annexia.org/freeware/rws --Tim Larson
