Does having the worker pool hold as many threads as cores work well alongside the async pool? It is basically oversubscribed by design.
I built a system once which had (this is Rust) a Rayon worker thread pool of 4 threads and a Tokio async pool of 2 (multithreaded runtime). On a system of 6 vCPU. This ended up working fine. Tokio was not starved so handled network requests at low latency.
One difference is DuckDB is a pure network client. If one of its async threads is starved it is not the end of the world (e.g. k8s does not kill your pod for failure of replying to health checks).
I've run quite a few benchmarks on that as well, on a few different machines, and oversubscribing ASYNC threads demonstrated very little performance downside. In the end, the memory governor also keeps these threads "in check" while still allowing full utilization when possible.
There is still something to gain from tuning it further (as you can see in the async I/O tuned benchmark), but having that network saturation by default is still a work in progress.
(Disclaimer: I'm the author of the blogpost)
As long as you're scheduled by the kernel and not something like Kubernetes with a CPU limit, you can generally oversubscribe I/O threads without much of a problem. They're mostly parked waiting for syscalls anyway. Heck, even if they're mostly doing CPU work, the scheduler generally deals with it pretty gracefully.