On Fri, 16 Sep 2016 07:29:28 -0400
Richard Hipp wrote:
> 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.
On 08/15/2016 12:02 AM, Венцислав Русев 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
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 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,
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
On 8/14/16, Венцислав Русев 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"
On 15 Aug 2016, at 1:02am, Венцислав Русев wrote:
> sqlite doesn't use these "auxiliary threads" that sqlite docs talks about and
> the runtime of that query is the same with or without "pragma threads = 4".
I cannot solve your problem, but this information may help the
7 matches
Mail list logo