Re: [sqlite] Transactions for SELECT

2011-11-22 Thread Dan Kennedy

On 11/22/2011 05:45 PM, Baruch Burstein wrote:

I will when I get the chance, but I am trying to get a list of things to
try to improve my SELECT speeds. If it is one SELECT, but returning +-1
rows, it probably won't make a difference, right?


No advantage in wrapping a single statement, of any type, in an
explicit transaction.





On Tue, Nov 22, 2011 at 11:41 AM, Dan Kennedy  wrote:


On 11/22/2011 04:34 PM, Baruch Burstein wrote:


Do transactions speed up SELECT statements?



They can a bit. If you put 10 SELECT statements in a transaction
SQLite only has to lock and unlock the database file once. If
you run them outside of a transaction the db is locked and unlocked
10 times.

Best to experiment to find out if this is significant for your
app.

__**_
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


Re: [sqlite] Transactions for SELECT

2011-11-22 Thread Simon Slavin

On 22 Nov 2011, at 10:45am, Baruch Burstein wrote:

> I will when I get the chance, but I am trying to get a list of things to
> try to improve my SELECT speeds. If it is one SELECT, but returning +-1
> rows, it probably won't make a difference, right?

Right.  It'll do a lock, then the SELECT, then an unlock.  So you're only out 
the time of two very short operations.

Slow SELECTs are most probably the result of the lack of an index which is good 
for the SELECT.  I see many examples where people have indexed each column 
individually, and that isn't a good way to do it.

Another thing that can do it is using "SELECT * ..." when you could specify 
individual columns.  And if you're expecting 10,000 records, then another is 
poor memory handling, by reading the entire results of a SELECT into memory 
rather than reading a row, processing it, then reading the next row, etc..

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


Re: [sqlite] Transactions for SELECT

2011-11-22 Thread Baruch Burstein
I will when I get the chance, but I am trying to get a list of things to
try to improve my SELECT speeds. If it is one SELECT, but returning +-1
rows, it probably won't make a difference, right?

On Tue, Nov 22, 2011 at 11:41 AM, Dan Kennedy  wrote:

> On 11/22/2011 04:34 PM, Baruch Burstein wrote:
>
>> Do transactions speed up SELECT statements?
>>
>>
> They can a bit. If you put 10 SELECT statements in a transaction
> SQLite only has to lock and unlock the database file once. If
> you run them outside of a transaction the db is locked and unlocked
> 10 times.
>
> Best to experiment to find out if this is significant for your
> app.
>
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>



-- 
Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.  - Rich Cook
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Transactions for SELECT

2011-11-22 Thread Dan Kennedy

On 11/22/2011 04:34 PM, Baruch Burstein wrote:

Do transactions speed up SELECT statements?



They can a bit. If you put 10 SELECT statements in a transaction
SQLite only has to lock and unlock the database file once. If
you run them outside of a transaction the db is locked and unlocked
10 times.

Best to experiment to find out if this is significant for your
app.

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


[sqlite] Transactions for SELECT

2011-11-22 Thread Baruch Burstein
Do transactions speed up SELECT statements?

-- 
Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.  - Rich Cook
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users