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
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
