On Thu, Oct 8, 2009 at 10:47 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> (This is making the assumption that a series of N non-transaction
> SQLite INSERT statements (which is to say, a series of N implicit
> transactions) is as efficient as one transaction with N INSERTs.
> Maybe it isn't; I'm not sure. Getting it out of the FSFS write lock
> would still be good, though.)
This is answered in http://www.sqlite.org/faq.html#q19. It isn't as fast:
(19) INSERT is really slow - I can only do few dozen INSERTs per second
Actually, SQLite will easily do 50,000 or more INSERT statements
per second on an average desktop computer. But it will only do a few
dozen transactions per second. Transaction speed is limited by the
rotational speed of your disk drive. A transaction normally requires
two complete rotations of the disk platter, which on a 7200RPM disk
drive limits you to about 60 transactions per second.
Transaction speed is limited by disk drive speed because (by
default) SQLite actually waits until the data really is safely stored
on the disk surface before the transaction is complete. That way, if
you suddenly lose power or if your OS crashes, your data is still
safe. For details, read about atomic commit in SQLite..
By default, each INSERT statement is its own transaction. But if
you surround multiple INSERT statements with BEGIN...COMMIT then all
the inserts are grouped into a single transaction. The time needed to
commit the transaction is amortized over all the enclosed insert
statements and so the time per insert statement is greatly reduced.
Another option is to run PRAGMA synchronous=OFF. This command will
cause SQLite to not wait on data to reach the disk surface, which will
make write operations appear to be much faster. But if you lose power
in the middle of a transaction, your database file might go corrupt.
And it is certainly at its right place in the FAQ.. Referenced it
three times in the last few days ;)
Received on 2009-10-08 23:48:42 CEST