Re: Skip prefetch for block references that follow a FPW or WILL_INIT of the same block

On Mon, Oct 26, 2026 at 8:52 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:

> I did not find a 16x amplification diagram in your github link. Maybe I am
> missing
> something?
>

The IOPS amplification was very clear from looking at the charts showing
Azure IOPS for the primary on the replica. But you're right that the github
link did not show the math. The 16x comes from the primary doing 128k reads
for seqscan and vacuum (whether due to io_uring or os readahead) while the
replica does 8k reads (i'm fairly confident linux wont do readahead). But
when I visually look at the charts, it actually seems a bit higher than 16x
- the replica was pegged at 500 IOPS for over 30 minutes. I'm doing a bit
more testing now to see if I can illustrate this more clearly.

> I also think that visibility map and FSM reads were the largest cause of
> > replica reads when prefetch was disabled
>
> In my understanding, these forks are quite small. VM is 1/4000 and most of
> them
> are constantly in memory, so not lots of IO required? For FSM, I dont
> think they are
> WAL logged and therefore they can not be recovery prefetched.
>

You're probably right about this. I did a run with FPIs enabled and cold
cache, that's why I noticed the FSM. I'm running some more tests now and
will see if this still seems concerning.

Additionally, most EBS-like block storage services offer a high
> IOPS-to-throughput
> ratio(usually 1:16-32kb), aggressive prefetching may not incur significant
> waste.
>

This is exactly the problem. Because of that ratio, if the workload is
entirely small 8k IO operations it can easily hit the IOPS ceiling while
the large 128k read workload runs very efficiently on the primary.

I'm doing some more testing, and seeing if I can also simplify the
reproduction by using two local cgroups instead of two VMs that need
separate disks. I'm also toying with a patch locally to add io_uring to
Tomas' patches, we'll see how far I get.

-Jeremy

--
http://about.me/jeremy_schneider

On Mon, Oct 26, 2026 at 8:52 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:

> Hi Jeremy,
>
> I feel a little bit confused, could you please share more about the
> following?
>
> > Vacuum is the more concerning case here, as large vacuums would
> consistently
> > cause the 16x IOPS amplification on replicas.
>
> I did not find a 16x amplification diagram in your github link. Maybe I am
> missing
> something?
>
> > I also think that visibility map and FSM reads were the largest cause of
> > replica reads when prefetch was disabled
>
> In my understanding, these forks are quite small. VM is 1/4000 and most of
> them
> are constantly in memory, so not lots of IO required? For FSM, I dont
> think they are
> WAL logged and therefore they can not be recovery prefetched.
>
> Additionally, most EBS-like block storage services offer a high
> IOPS-to-throughput
> ratio(usually 1:16-32kb), aggressive prefetching may not incur significant
> waste.
>
> This extra throughput capacity would likely go underutilized, especially
> it is running heavy sequential scan prefetching.
>
> Thanks,
> Shihao
>

--
http://about.me/jeremy_schneider