> 3. Start a transaction and hold the DB read locks for the duration of your application (again, if it won't need writing)
I had a look at this but couldn't see a speed increase. This was for a single statement, so that is repeated (in a loop) sqlite3_step, sqlite3_column_xxx etc. In what situation should this increase read speed? RBS On Wed, Jan 17, 2018 at 8:48 AM, R Smith <[email protected]> wrote: > On 2018/01/17 8:48 AM, Nick wrote: > >> Thank you Simon. >> >> As you said, UNIQUE(b, i) is redundant, but I guess it will not affect the >> performance of the SELECT. >> >> I find "SEARCH TABLE t1 USING INDEX sqlite_autoindex_t1_1 (b>?)" when I >> use >> EXPLAIN QUERY PLAN, so I do not need to add any index, right? >> >> Um, I guess I have nothing to do to improve the performance. >> Thanks. >> > > Hang on a second - True, there is nothing to be done to improve the speed > of that specific Query - BUT - there is plenty to be done to improve the > speed of the database for your specific use case. The usual suspects that > comes to mind are: > > 1. Use a faster Journal mode (Have to weigh speed against > power-loss-data-integrity-protection), > 2. Use an in-memory DB (especially if you only reading from it) > 3. Start a transaction and hold the DB read locks for the duration of your > application (again, if it won't need writing) > 4. Ensure there are no other time-consuming bits of code in the sqlite api > RESET()-STEP() loop. (And if you are accessing it through a wrapper, stop > that and use the api directly). > > We could and would probably give more useful direct advice if we know a > lot more about your specific use case, platforms, access-method and setup. > > Cheers! > Ryan > > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
