"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.
Now that you mention this, I remember someone in this list that suggested
for me to break this table down into closed projects (many), archived
projects (the list keeps growing) and open projects. So, thanks for this
reminder. I just have to write another email to this list later when I make
those changes to see how I would search in all tables (Archived, Closed and
Open) for all projects (archived, closed and opened) that belong to, say
cust='Xerox', but, that will be later. :-)
Thanks.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
