Hi Jeremy, I think I missed reading your github link yesterday night. I agree it shows IOPS difference between primary and replica.
After digging in a bit more (thanks to your blog[1]), I noticed the current prefetcher always calls FADVISE before pread, which looks like bypass OS readahead for sequential access. In the replay path, this may happen right after the primary finishes a large sequential write (e.g., vacuum or a full-table update). But I am not sure if these workload are common because most of the time vacuum can skip pages and the write is not purely sequential and full-table update is not that common as well. But I agree this is a problem we need to fix. > This is exactly the problem. Because of that ratio..... I think repeated fadvise calls on continuous blocks would not trigger OS prefetch and we'd be turning sequential I/O into random I/O, burning more IOPS while leaving bandwidth underutilized..... [1] https://ardentperf.com/2026/10/20/postgres-recovery_prefetch-considered-harmful-and-causing-outages/ Thanks, Shihao
