Hi, On 2025-02-14 10:04:41 +0100, Jakub Wartak wrote: > Is there any reason we couldn't have new pg_test_iorates (similiar to > other pg_test_* proggies), that would literally do this and calibrate > best e_io_c during initdb and put the result into postgresql.auto.conf > (pg_test_iorates --adjust-auto-conf) , that way we would avoid user > questions on how to come with optimal value?
Unfortunately I think this is a lot easier said than done: - The optimal depth depends a lot on your IO patterns, there's a lot of things between fully sequential and fully random. You'd really need to test different IO sizes and different patterns. The test matrix for that gets pretty big. - The performance characteristics of storage heavily changes over time. This is particularly true in cloud environments, where disk/VM combinations will be "burstable", allowing higher throughput for a while, but then not anymore. Measureing during either of those states will not be great for the other state. - e_io_c is per-query-node, but impacts the whole system. If you set e_io_c=1000 on a disk with a metered IOPS of say 1k/s you might get a slightly higher throughput for a bitmap heap scan, but also your commit latency in concurrent will go through the roof, because your fdatasync() will be behind a queue of 1k reads that all are throttled. Greetings, Andres Freund
