At 06:53 04/08/2011, you wrote: >I was hoping they wouldn't block each other because it's a read >lock. I tried making an index on all the columns, but R*tree table + >JOIN that I'm using runs about 10x faster. I might have done >something wrong, so I'm open to suggestions on a better index, though.
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. >I don't think that UPDATEing 99.99% of 17 million columns is going >to run faster than the pure select statement that I have. Each >select statement is fairly random, a small selection out of an >N-dimensional space. 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. >Am I understanding you? Any other ideas? >~Seth _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
