On Sat, Apr 5, 2014 at 9:16 AM, big stone <stonebi...@gmail.com> wrote:
> Hello, > > I see the "threads" branch of fossil has a lot of activity and seems close > to be finalized. > No, it still has a long way to go. > > Will it be activated by default on the downloadable executable for windows > ? > Probably not. It might be possible to activate this feature using a PRAGMA. Or, it might require a start-time or compile-time setting. That is still all very much in flux. > Will it apply to parallelisable CTE expression ? > No. Multiple cores will only be used by CREATE INDEX and by large ORDER BY or GROUP BY statements that cannot be satisfied using indices. Devoting 4 cores to the task allows large ORDER BY statements to go about 25% faster. > > Will it be possible from 1 sqlite.exe command line (or 1 python > sqlite.execute) to launch several SQL in parallel (and separated threads) ? > No. > > Typical workload case (that would be awesome if it could be 4 times > quicker) = > > ******************************************************************************************** > - a long treatment reading a big table, which could be splitted into N > treatments reading 1/N th of the records of the big table. > - the N thread are adding the resulting records in 1 table. > > This typical workload could also be defined as a big CTE : > with > resulset1 as (...), > resulset2 as (...), > resulset3 as (...), > resulset4 as (...) > select * from resultset1 > union all > select * from resultset2 > union all > select * from resultset3 > union all > select * from resultset4 > > Regards, > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
