that is a single sql statement though ; it doesn't spread itself amongst threads, the compile option says 'limits number of threads' so if you had an application (not sqlite shell) that had threads it could have a limit?
On Fri, Sep 16, 2016 at 5:13 AM, Adam Devita <adev...@verifeye.com> wrote: > Have you proven that the cpu is the bottleneck? Sorting a million rows > seems like a lot, but even older single core cpus may be capable of 2 > billion ops per second. [I apologize if this has been sorted out > already.... I've got about 2 days of history on the thread] > > regards, > Adam DeVita > > On Fri, Sep 16, 2016 at 7:56 AM, Stephen Chrzanowski <pontia...@gmail.com> > wrote: > > > Although programmatically easily done, from the SQLite point of view, > what > > if that query, sans LIMIT, were a subquery, and the limit was put out on > > the outside? Would the inner query execute, use all the threads, then > > return just one row on the outer? > > > > On Fri, Sep 16, 2016 at 7:29 AM, Richard Hipp <d...@sqlite.org> wrote: > > > > > On 8/14/16, Венцислав Русев <ven...@proxima-3.com> wrote: > > > > My computer has 4 cores. I have compile sqlite like this "gcc > > > > -DSQLITE_MAX_WORKER_THREADS=4 -DSQLITE_DEFAULT_WORKER_THREADS=4 > > shell.c > > > > sqlite3.c -lpthread -ldl -o sqlite3". I made some tests and found > that > > > > "pragma threads = 4" doesn't decrease runtime of the query that > sorts 1 > > > > milion records. > > > > > > > > SQLite version 3.8.8 > > > > sqlite> pragma threads; > > > > 4 > > > > sqlite> CREATE TABLE event ( > > > > ID INTEGER PRIMARY KEY NOT NULL, > > > > date INTEGER NOT NULL, > > > > value INTEGER NOT NULL ); > > > > sqlite> EXPLAIN QUERY PLAN SELECT ID FROM event ORDER BY date LIMIT > 1; > > > > > > The algorithm used for "ORDER BY ... LIMIT N" uses much less memory > > > than a full-up "ORDER BY" because is only keeps track of the top N > > > entries seen so far, discarding the rest. But it also only uses a > > > single thread. If you want multiple threads to be used, you'll need > > > to drop the LIMIT, though I imagine that would defeat your purpose, > > > no? > > > > > > -- > > > D. Richard Hipp > > > d...@sqlite.org > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@mailinglists.sqlite.org > > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > > -- > -------------- > VerifEye Technologies Inc. > 151 Whitehall Dr. Unit 2 > Markham, ON > L3R 9T1 > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
