On Friday, 4 March 2016 at 22:22:48 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 4 March 2016 at 03:14:01 UTC, Ali Çehreli wrote:.
And that's exactly one of the benefits of fibers: two workers
ping pong back and forth, without much risk of losing their
cached data.
Is my assumption correct?
Not if it is hyper-threaded, as pairs of threads are sharing
resources.
Irrelevant.
Otherwise you are just benchmarking a suboptimal pattern. Which
makes sense when optimizing an existing application, but makes
less sense when designing a new database engine from scratch.
async do not make any sense on a DB. You want async when you are
bound by a 3rd party system.
For instance, if you have a frontend server that is bound by DB
access, async will allow to shift you frontend code from DB bound
to CPU bound, allowing you to get much more bang for the buck in
your frontends. Now, if you limiting factor is IO on your own
machine, like say local disk access, then it's going to change
nothing (in fact, it may make things much worse as disk prefer
sequential accesses).
