On Mon, Jan 09, 2006 at 09:08:10PM -0800, Dan Kennedy wrote: > > > --- "Jim C. Nasby" <[EMAIL PROTECTED]> wrote: > > > On Mon, Jan 09, 2006 at 06:47:04PM +0100, Eduardo wrote: > > > of transactions per second. But because each transaction requires at > > > least two revolutions of the disk platter, SQLite is limited to about > > > > Why does a transaction commit require two seperate writes? > > -- > > Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] > > Pervasive Software http://pervasive.com work: 512-231-6117 > > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > > > The short version: > > The first write operation writes the parts of the database that > are about to be overwritten to the journal file. If something > goes wrong during the second write, the journal file will be > used to restore the database to it's previous state. The second > write is the one that actually modifies the database file.
Yes, but the second write (to the data files) isn't time critical. Because it doesn't (or at least shouldn't) be getting fsync'd very often, it can also be re-ordered by the OS (and possibly the drive). In any case, it's completely inaccurate to say that each transaction requires two revolutions of the drive. Also, if SQLite supports it, putting the log files on a seperate set of drives from the tables is almost always a win. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
