Thanks to all that replied to my post and sorry for the delayed response. I had trouble joining the list and had not realised that my post went through until I tried to join the list again.
Simon Slavin slavins at bigfraud.org wrote: > What you might find increases your speed is to make sure that those 8 columns > are the first 8 columns listed in your table definition (after the primary > key, if any). Each time you have SQLite read the columns for a row it has to > read the whole row up to the last column it needs. So if all the unwanted Thanks, intriguing idea. Unfortunately made no difference for my situation. I made sure the table was too large to be cached, and I was using count(first_field) instead of selecting all the fields, can't imagine that could be the problem. > Lastly, do not fall into the trap of premature optimization. You should not > be looking for your program to run "as fast as possible". You should be > > looking for it to run "acceptably fast". You can spend 20 hours of > programming to improve > runtime by 1 minute -- a minute that your users wouldn't care about because > they always go > make a cup of coffee during a run anyway. Yeah I am wary of that. The queries take about 20 minutes, and really disrupts my workflow. If I spend a few hours on this and it works, it'll save me hundreds of hours in the long run. I like to collect anecdotal performance advice, and implement it when the cost of doing so is not much more than not doing it. I have some evidence that the approach has worked for me in the past. Thanks, Paul _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
