Why does the coroutine read executor default to one thread? #15246

DBOptions::read_io_executor_threads currently defaults to 1. Is there a particular reason for this default, rather than deriving it from available CPU concurrency?

I understand that one io_uring event-loop thread can keep many reads outstanding. However, the coroutine read executor also runs lookup and decompression work between I/O operations. With the default filesystem sharing this executor across databases, the default appears to limit that CPU work to one thread across concurrent coroutine reads.

We use RocksDB through a Node.js native binding and are considering running native request preparation and result packing on the same executor to avoid additional thread-pool handoffs. Understanding the intended sizing policy would help.

A few related questions:

1. Is 1 primarily a conservative resource default, or is there benchmark evidence supporting it for typical coroutine-read workloads?
2. Would a default based on available CPU concurrency be appropriate, while retaining an explicit override?
3. DBOptions::IncreaseParallelism() configures background flush/compaction pools but leaves the read executor unchanged. Is this separation intentional, and should the documentation explicitly say that asynchronous read concurrency must be configured separately?
4. Is there recommended guidance for sizing this executor alongside background jobs and application threads?

This is a question about the default and configuration guidance; we have not yet established the optimal thread count for our workload.

Relevant implementation: read_io_executor_threads in include/rocksdb/options.h, and the executor binding in DBImpl::MultiGetCoroutine.