> so whenever an OS thread is blocked the OS scheduler simply schedules another OS thread Go does that even now. If a thread is blocked, it would create anoth

> so whenever an OS thread is blocked the OS scheduler simply schedules another OS thread Go does that even now. If a thread is blocked, it would create another thread, but it does it with a small delay. I saw a visible increase in IOPS when starting Go with more OS threads (using GoMAXPROCS), because Go doesn't need to wait before having access to these threads, but on a longer running job with enough initiation for OS threads, that benefit would be nullified. Most LSM based KV stores are designed to avoid random lookups -- and Go DBs tend to use RocksDB -- so it probably hasn't been such a big issue for them.