----- Original Message ---- > From: Joe Wilson <[EMAIL PROTECTED]> > The disk read/write reordering optimization only works if the > database file is contiguous on the disk and not fragmented.
> --- [EMAIL PROTECTED] wrote: > > Basically, the db file is accessed with seek + read/write operations. > > Given a set of such operations, it can be very beneficial to reorder those > > operations so that > > the file is accessed going from the begining to the end of the file (and > > not pure random). > > This is a problem mostly for reads (writes are reordered when doing a > > combination of async > > writes + flush at the end). This was my first idea on trying to speed things up, after that I realized that there had to be a better and more reliable way to do async i/o. In fact, I found that the aio API does exactly that See http://mia.ece.uic.edu/~papers/WWW/books/posix4/DOCU_008.HTM The aio_read/aio_write + aio_suspend calls are POSIX and available on linux, bsd, solaris (and Windows event api is very similar to it). This api, when used with aio_suspend will not rely on signals like SIG_IO, but only on low level kernel signals (invisible to the application), making this thread safe and pretty much without any side effects on the rest of the application (that uses sqlite). After finding out about this api, I found out that at least mysql and postgresql use it, so I am guessing that changing the sql engine to generate batches of read/writes is possible. My guess is that using this api will increase performance a lot as the hard drive heads won't have to go back and forth, seeking at random places on the disk (thus reducing the impact of having small caches). Nicolas
