On Friday, 27 December, 2019 16:37, Simon Slavin <slav...@bigfraud.org> wrote:
>On 27 Dec 2019, at 9:57pm, Keith Medcalf <kmedc...@dessus.com> wrote: >> Setting "SINGLETHREAD" does indeed disable the multithreaded sorters. >> When in one of the multithreaded modes, that query utilizes an average of >> 60% CPU, compared to 12% when running singlethreaded. >So if I understand this right, SQLite in multithread mode can itself use >multiple threads at once, which means it can use many cores at once, >which means it might be faster, most likely for complicated queries which >involve lots of different things to be done. >I'm slightly stunned. That had never occurred to me. Thank you. Only sort operations are candidates for internal multi-threading in SQLite at the moment and then only if all the following conditions are met: - the amount of data to be sorted exceeds page_size * min(cache_size, pmasz) bytes - the library is compiled with SQLITE_DEFAULT_WORKER_THREADS greater than 0 (the default is 0) OR pragma threads=X; is used to set the default number of threads to a value greater than 0 at runtime for a connection OR sqlite3_limit(db, SQLITE_LIMIT_WORKER_THREADS ...) C interface is used to set a >0 number of threads for a connection - SQLITE_MAX_WORKER_THREADS is greater than 0 (the default is 8) - the threading mode is not SQLITE_SINGLETHREAD -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
