On Aug 4, 2011, at 1:54 AM, Eduardo Morras wrote: > > They block each other not trying to get a lock, but trying to get > access to disk and cache. Disk access time and cache is shared > between all threads and if all threads needs access to different > parts of the db they will figth like barbarians, you should convert > them to roman cohorts instead. You can make your page cache size > bigger using pragmas, check maillist and documentation.
Using a 10x larger temp cache and default cache at compile time increases my runtime of that section from 166 to 167. I'm using two threads still. > You don't need to update your table, you can use a temp memory table > for that with candidates. First select candidates where 57<col0min, > then you delete candidates from temp table where col0min<62 and so > on. You don't need to copy the original table schema for temp table, > use pk only. The select of the first candidates is important, use the > one that minimizes the number of initial data. I was hoping that SQLite was doing that with the JOIN statement. It's narrowing down the results with the query from the R*table (col*min & col*max). A large query will have ~14k rows at this point. Then JOINs with the original table (data) and it's narrowing results further with the remaining part of the WHERE (col*). The large query will have ~11k rows. After this it groups by the 'class' column in 'data' and counts how many rows per class. I'm really skeptical that I can chop this up into many queries to make it run faster. I've always assumed that if I can get "final" data back from a query, then it's exactly the query I'm looking for. I would think that running three queries would use three times the resources. Thanks, Seth _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
