Wrapping virtual threads in predefined ExecutorService.

[Ron Pressler]

I agree it can be beneficial, but you should beware of generalisations. Most of the work is not in the scheduling scheme but in designing the database and its user model in a particular way *so that* thread-per-core could then give an extra boost. Also, designs that work well in languages where heap allocations are generally expensive (C) don’t necessarily help to the same degree in languages where allocations are relatively cheap (Java).

A particular optimisation needs to fit your algorithm/data structure design as well as the language’s other constraints for it to be maximally effective.

— Ron

> On 17 Jun 2023, at 13:00, Andrii Lomakin <lomakin.andrey at gmail.com> wrote:
> 
> Attila, 
> 
> While I understand and respect your opinion, I must disagree. Through practical examples, it has become evident that thread-per-core architecture and asynchronous IO are incredibly beneficial in database development. These techniques are used in ScyllaDb and their SeaStart framework (written in C) https://github.com/scylladb/seastar, and are demonstrated in a project I took part in myself https://www.datadoghq.com/blog/engineering/introducing-glommio/, https://github.com/DataDog/glommio (written in Rust). The results have been quite noticeable in practice.