Based on what I've read, it certainly could. As I understand it, there is a single queue for all the writes so the writes for multiple databases, journals, etc. are going to that single queue. Based on that, it is certainly "possible" that your overall throughput and throughput for any individual database could be negatively affected.
Note that my file system knowledge is restricted to Windows platforms. Please don't extend my speculation to other platforms. I also note that I have done no performance testing with this VFS myself and have seen no data provided. Doug wrote: > Would this perhaps affect throughput in the case where multiple database > files are open? For example, I have a handful of databases (10?) that are > open at any given time, and reads and writes are taking place on separate > threads. Naturally writes that happen to the same database ultimately get > serialized by the database-level locks, but writes to other databases > continue to work. But using the async feature would serialize all reads and > writes to all databases, is that correct? > > Thanks > Doug > > >> -----Original Message----- >> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- >> boun...@sqlite.org] On Behalf Of Christian Smith >> Sent: Friday, May 08, 2009 7:24 AM >> To: General Discussion of SQLite Database >> Subject: Re: [sqlite] SQLite version 3.6.14 >> >> On Fri, May 08, 2009 at 05:32:45PM +0700, Dan wrote: >> >>> On May 8, 2009, at 5:21 PM, Christian Smith wrote: >>> >>> >>>> On Wed, May 06, 2009 at 10:36:50PM -0400, D. Richard Hipp wrote: >>>> >>>>> A new optional extension is included that implements an >>>>> asynchronous I/ >>>>> O backend for SQLite on either windows or unix. The asynchronous >>>>> >> I/O >> >>>>> backend processes all writes using a background thread. This >>>>> >> gives >> >>>>> the appearance of faster response time at the cost of durability >>>>> >> and >> >>>>> additional memory usage. See http://www.sqlite.org/asyncvfs.html >>>>> >> for >> >>>>> additional information. >>>>> >>>> What are the benefits of using async I/O over "PRAGMA synchronous = >>>> OFF"? >>>> If AIO is used for the rollback journal as well, you've lost your >>>> >> ACID >> >>>> properties already, so you may as well just use "PRAGMA synchronous >>>> = OFF" >>>> anyway and keep the code simpler. >>>> >>> That's not the case. You lose the Durability property, in that a >>> >> COMMIT >> >>> statement may return before a transaction is stored on the persistent >>> media, >>> but transactions are still Atomic, Consistent and Isolated. >>> >>> When using the "PRAGMA synchronous=off" your database might be >>> >> corrupted >> >>> by a power failure or OS crash. When using asynchronous IO this >>> >> should >> >>> not >>> be possible (assuming the hardware is not being untruthful - just as >>> when >>> using regular "PRAGMA synchronous=full" mode without the async IO >>> >> VFS). >> >> >> Ah, the bulb has lit. Because the writes and syncs are processed by the >> single queue in order, journal writes are guaranteed to be synced and >> consistent before main in-place updates to the db file. >> >> Might be worth mentioning this in the documentation, as this is not >> clear without examining the source. >> >> In that case, I like it :) >> >> Is this something that might be made the default in the future, with >> the >> addition of some synchronization between foreground and background >> threads >> on the xSync messages to emulate the existing "PRAGMA synchronous=full" >> behaviour? >> >> >>> Dan. >>> >> Christian >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
