On 28.03.2013 14:03, Jeff Archer wrote:
On Thu, Mar 28, 2013 at 8:24 AM, ibrahim <ibrahim.a...@googlemail.com> wrote:
On 28.03.2013 13:09, Jeff Archer wrote:
On Wed, Mar 27, 2013 at 6:35 PM, Simon Slavin <slav...@bigfraud.org>
wrote:
Reasonable figures.  With 5764 writes to the disk in separates
transactions you have quite a lot of reading of data plus 5764 attempts to
update the database file.  The updates have to be done in the right order,
and each update has to wait for the disk to be rotated into the right
position, though each update changes only a small amount of data (probably
two sectors).
But my most basic question remains.  Why is single transaction faster
than PRAGMA journal_mode = off?

Seems to me that with no journal there should only be single set of
writes to the actual db and that journaling would double the number of
writes because data has to be written to journal file as well.

2.5 sec with journal
5.5 sec without journal   <= seems like this sould be the smaller number

You should read the sections 3 forward.

http://www.sqlite.org/atomiccommit.html

A single transaction happens mostly in memory then is flushed to the OS
Cache in one step. The Journal file (the amount of pages that will be
changed) is small while inserting new data into a database and the OS File
Cache is usually large enough ...

Yes, I have read this.  (And now re-read it)

So, since much more work must be done when using journal file, why
does it take longer to do the inserts when there is NO journal file?
_______________________________________________

You compare different approaches. You should compare

a) Journal mode=on  w/wo single transaction
b) Journal mode=off w/wo single transaction

Single transaction outweights journal mode in terms of performance. It reduces the amount of necessary physical read write operations on the OS File Cache and the Disk.


_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to