Re: DBI::SQLite slowness

You must perform SQLite operations in a transaction, because if you do not, it will re-read and re-verify e-v-e-r-y I/O operation, by design.

Comment on Re: DBI::SQLite slowness

Replies are listed 'Best First'.
Re^2: DBI::SQLite slowness by Endless (Beadle) on Sep 20, 2013 at 17:59 UTC
If I simply have "$dbh->commit" following the For loop, is that effectively the same as explicitly using transactions?	[reply]
Re^3: DBI::SQLite slowness by erix (Prior) on Sep 21, 2013 at 13:13 UTC
If I simply have "$dbh->commit" following the For loop, is that effectively the same as explicitly using transactions? No; BEGIN WORK (or BEGIN TRANSACTION or just plain BEGIN) starts a transaction in SQL. Then (normally after 1 or more insert/delete/update's) COMMIT commits the transaction (or, when an error occurs, ROLLBACK rolls the transaction back to the state just before the BEGIN). See DBI's begin_work (I don't use SQLite; in the above I am assuming SQLite does this the same way that other (RDBMS) databases do)	[reply]
Re^4: DBI::SQLite slowness by Endless (Beadle) on Sep 21, 2013 at 18:20 UTC
Thanks for the tip; it will come in handy when I switch to other databases. Looks like DBI::SQLite keeps that all under the hood, though, with transactions implicitly invoked if autocommit is off. See https://metacpan.org/module/DBD::SQLite#Transactions	[reply]
Re^5: DBI::SQLite slowness by erix (Prior) on Sep 22, 2013 at 05:12 UTC