On 22 Nov 2011, at 10:45am, Baruch Burstein wrote: > I will when I get the chance, but I am trying to get a list of things to > try to improve my SELECT speeds. If it is one SELECT, but returning +-10000 > rows, it probably won't make a difference, right?
Right. It'll do a lock, then the SELECT, then an unlock. So you're only out the time of two very short operations. Slow SELECTs are most probably the result of the lack of an index which is good for the SELECT. I see many examples where people have indexed each column individually, and that isn't a good way to do it. Another thing that can do it is using "SELECT * ..." when you could specify individual columns. And if you're expecting 10,000 records, then another is poor memory handling, by reading the entire results of a SELECT into memory rather than reading a row, processing it, then reading the next row, etc.. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
