On 10/2/09, Pavel Ivanov <paiva...@gmail.com> wrote: > > It seems a bit disingenuous to claim > > there will be no performance gain by putting selects in a transaction, > > when sqlite clearly does less work with the transaction (in the form > > of not getting the read lock multiple times). > > > It's pretty ingenuous in fact to silently assume that nobody wants to > do 50000 selects at once. Lower that to 5 (already a huge amount of > work for "one request to database" that blocks out any writers) or to > 1 (the real number when somebody speaks about "difference of putting > select inside transaction") and you'll get a difference of 0.08 ms or > 0.016 ms which is pretty small number to ignore when it's compared to > the time of actual reading from disk for the actual select.
Sorry, I was not aware of these implicit assumptions. Nor did I mean to imply that you were being disingenuous -- you have answered in 10 minutes what took me several hours to narrow down to my original example. I guess my usage is a bit peculiar, where the results of a single select must be analyzed to determine what to select next, and this can potentially cascade into many other selects, which must also be analyzed, and so on. During this time no writes are allowed (due to other requirements that I have), so for me there is no other consideration as to whether or not it is in a transaction. Thanks for your help, -Mike _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
