All my searches are unique and go across the whole table. The range I select from us normally between 500 and 600 rows.
I benchmarked the select over the growth of the database to circa 4m records and the slowdown was negligible. I'm not looking at optimising it as I have far better candidates for optimisation (sadly). I'm still building the application and still adding data, and may double the test database size over the next week. I'm confident (famous last words) it won't be a problem (stop sniggering at the back there). -- Rob On Wednesday, 16 July 2014 at 15:49, RSmith wrote: > > On 2014/07/16 14:23, jose isaias cabrera wrote: > > "Simon Slavin" wrote... > > > > > > That way is not particularly slow. You just need to have a good index. A > > > good index for that search would be > > > > > > CREATE INDEX sci ON startcodes (code,id) > > > > > > You will find that that SELECT will then be blisteringly fast even with > > > millions of rows in your table. > > > > I do have that INDEX for that id and table. Thanks. :-) I was just trying > > to be greedy and see if I could become even faster. > > Thanks for your help. > > > > > Greed is good in this regard :) > > Are all the searches unique or do you repeat a lot of searches for a very > specific range? If the latter, then partitioning the table > (well in SQLite that would really be a second derived table) might speed > things up if space is not an issue, but I would only invest > the design time for this once the standard query is proven to be slow - which > might be the case. > > _______________________________________________ > 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
