On Apr 23, 2009, at 10:05 PM, Pavel Ivanov wrote: > I think, this will be an awesome option for me, thanks! > I believe you are talking about sacrificing consistency not only over > power outage but over SIGKILL too, right? It's a bit worse to have > though I think it will be acceptable in my case, because more stable > response time is more important for me than Durability.
Depends on exactly what you mean by those terms. "Consistency" is not sacrificed in that there is (we hope) no chance that your database can become corrupted because of a power outage or application crash. There is no chance that a transaction could be partially committed either. Normally, once a COMMIT statement has executed successfully you are guaranteed that the transaction is on the persistent media. This is called "durability". But, when using the asynchronous IO backend, there is a chance that you could call "COMMIT" and have SQLite return SQLITE_OK, then later on find your transaction wasn't really committed to disk at all as a result of a power or application failure. > BTW, concerning memory consumption: I'm ready to consume more memory. > In fact I'm ready to consume like 10 times more memory than it's > nowadays. And I thought that I can increase sqlite's cache_size pragma > which will give me better performance on readings because most data > will be already in cache and there will not be disk readings. But to > my big surprise when I tried to set cache_size more than default value > of 2000 I've got sqlite working much slower. Is there something in > using cache inside sqlite that I don't understand or there's some > other explanation to this? > > > Pavel > > On Thu, Apr 23, 2009 at 10:48 AM, D. Richard Hipp <d...@hwaci.com> > wrote: >> >> On Apr 23, 2009, at 10:39 AM, John Stanton wrote: >> >>> Running in an unsafe mode for speed does not mean that ultimately >>> there >>> will have to be no writes, >>> >>> Perhaps you could devise a system where you post writes to a queue >>> and >>> have another thread or process perform the writes asynchronously. >>> You >>> would then use otherwise idle machine time for writing and avoid the >>> "freezing". >> >> >> FWIW, we are in the process of "productizing" the test_async.c >> asynchronous VFS for SQLite. The new async VFS might be available as >> a compile-time option or as a loadable extension on both windows and >> unix in 3.6.14. If not in that release, then probably in one of the >> next few releases. >> >> The async VFS does all disk writes in a background thread, so that >> from the main thread writes appear to be nearly instantaneous. >> Atomicity, Consistency, and Isolation are still guaranteed, though >> you >> do sacrifice Durability. In other words, if you cut the power to the >> machine, your last few transactions that supposedly where committed >> might get rolled back when power is restored. >> >> The async VFS also uses more memory, since the data waiting to be >> written to disk has to be stored somewhere. It might use a lot more >> memory if you are committing changes to the database faster than the >> disk and the background writer thread can handle them. >> >> D. Richard Hipp >> d...@hwaci.com >> >> >> >> _______________________________________________ >> 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
