Fork me on GitHub
#sql
<
2019-10-02
>
kulminaator20:10:07

not sure what you'd actually gain by that async/non-blocking stuff 🙂

gklijs04:10:59

I get the impression that a lot of people think that async is faster. But in reality it's often slower because of the overhead. Especially in JVM land where you could use hundreds of threads if you wanted to.

murtaza5217:10:04

@U26FJ5FDM my understanding was that the context switching that will take place with hundreds of threads will be slower as compared to the async scheduling, is that not the case ?

gklijs17:10:38

Could be, but it's not me experience. It's probably hard to something generic about it, since it matter a lot on how contexts and threads are implemented, and how it interacts with the 'real' cpu threads and different cpu cashes.

murtaza5217:10:50

A noob question, are java threads different from the real CPU threads ? I thought there is a 1-1 correspondence, bcoz usually the thread pool is initialized based on the number of cores available.

kulminaator18:10:00

on most platforms, it is 1-1 ... but if you spin up so many threads with db queries that this becomes an issue your database is long dead

kulminaator20:10:36

most databases still run on a limited set of disks, you will peak out their i/o with a handful of queries already in most cases

kulminaator20:10:38

nothing gets better once you tap the limit of i/o speed or disk operations per second