On Fri, Aug 29, 2025 at 7:52 AM Andres Freund <and...@anarazel.de> wrote: > On 2025-08-28 19:08:40 +0200, Tomas Vondra wrote: > > From the 2x regression (compared to master) it might seem like that, but > > even with the increased distance it's still slower than master (by 25%). So > > maybe the "error" is to use AIO in these cases, instead of just switching to > > I/O done by the backend. > > If it's slower at a higher distance, we're missing something.
Enough io_workers? What kind of I/O concurrency does it want? Does wait_event show any backends doing synchronous IO? How many does [1] want to run for that test workload and does it help? FWIW there's a very simple canned latency test in a SQL function in the first message in that thread (0005-XXX-read_buffer_loop.patch), just on the off-chance that it's useful as a starting point for other ideas. There I was interested in IPC overheads, latch collapsing and other effects, so I was deliberately stalling on/evicting a single block repeatedly without any readahead distance, so I wasn't letting the stream "hide" IPC overheads. [1] https://www.postgresql.org/message-id/flat/CA%2BhUKG%2Bm4xV0LMoH2c%3DoRAdEXuCnh%2BtGBTWa7uFeFMGgTLAw%2BQ%40mail.gmail.com
