So in this case I'm running on a 72 core machine. Also the databases have one table in them each... The goal here is to bring all the cores to bear on the many queries - each grabbing the next query to be run and running it, until finally there are no more chunks to run.
Then within my own apis I aggregate the results and form my response. I'm going to try preparing all the statements before I run any later tonight. I'm also toying with the idea of using a shared nothing architecture, in which I run 72 processes instead of threads, in the hope that there will be less contention that way. Thoughts on that idea? I really appreciate everyone's responsiveness. On Mar 3, 2017 4:19 PM, Jens Alfke <j...@mooseyard.com> wrote: > On Mar 3, 2017, at 3:51 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > Then mess with the '5' until you find a good value. A common rule of thumb with thread pools is to allocate one thread per CPU core. —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmailinglists.sqlite.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsqlite-users&data=01%7C01%7Candrew.brown%40economicmodeling.com%7C1941086b72c84122e80e08d462942220%7C7cc1677566a34e8b80fd5b1f1db15061%7C0&sdata=ytN2iaMT9eiK%2BktzJva1shKgrBfYhxeUHyesJscJnB8%3D&reserved=0 _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
