Then how's about we update the docs?  I can understand the need for consistency 
but never would've guessed that it sped things up so much.  A hint in the docs 
would help.



Michael D. Black

Senior Scientist

Advanced Analytics Directorate

Advanced GEOINT Solutions Operating Unit

Northrop Grumman Information Systems

________________________________
From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of Dan Kennedy [danielk1...@gmail.com]
Sent: Wednesday, November 02, 2011 11:05 AM
To: sqlite-users@sqlite.org
Subject: EXT :Re: [sqlite] does sqlite3_reset have a performance impact 
onqueries?

On 11/02/2011 08:13 PM, Black, Michael (IS) wrote:
> Maybe my memory is fading but this is the first time I've heard anybody say 
> the wrapping a BEBIN around a SELECT was needed.  I'd swear it was always 
> said it wasn't ever needed.
>
>
>
>> From the docs
>
> http://www.sqlite.org/lang_transaction.html
>
> basically, any SQL command other than 
> SELECT<http://www.sqlite.org/lang_select.html>) will automatically start a 
> transaction if one is not already in effect
>
>
>
> Now you're saying SELECT always starts a transaction?

There are two types of transactions - read-only transactions and
read/write transactions.

A read-only transaction contains only reads. All reads that occur
within a single read transaction see the same snapshot of the
database. Logically, they are useful when you have one or more
SELECT statements to run and you don't want anybody else modifying
the database between them. If you don't wrap a SELECT in a
BEGIN/COMMIT block, then it will open and close its own
read-transaction.

But, read-transactions can also speed things up in SQLite - since
you don't have to lock and unlock the database file (and do some
other stuff too) for every SELECT.

_______________________________________________
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

Reply via email to