On Wed, Nov 18, 2015 at 11:56:50PM +0000, Simon Slavin wrote: > On 18 Nov 2015, at 10:58pm, Nico Williams <nico at cryptonector.com> wrote: > > Can SQLite3 run the sub-queries of a UNION ALL with any degree of > > concurrency? E.g., with its co-routines? > > SQLite always has the bottleneck of access to the file storage medium. > Many posts to this list have complained that implementing > multi-threading or multi-processing does not speed up SQLite > significantly, and in some cases makes things worse.
But two concurrent scans of the same table should be able to go faster than the same two scans in series. > The problem here is not that SQLite does this job inefficiently, but > that the job is a bit weird. If you know you're going to have to diff > two versions of the same database, you have your program write a log > of the modifications it makes. So weird that sqldiff exists. Huh. Writing a log is a nice idea that doesn't always work. There's no need to go into that in detail. Suffice to say that a) I do use logs in some case, b) diff'ing two tables is not such crazy thing to want to do. There's a whole class of problems that SQL query optimizers don't do as well with as a programmer writing a general purpose programming language can do. This is, IMO, an interesting problem. I'm not just after "how can I do this faster", but "how can SQLite3 do this faster". I understand and accept, of course, that the SQLite3 dev team may not be interested in the latter. Thanks, Nico --
