Re: improving handling of FPIs during recovery prefetching

Hi Tomas,

On 10.11.26 13:20, Tomas Vondra wrote:
> FYI I had a chat with Thomas Munro, who wrote the current recovery
> prefetcher, and he has some ideas for an alternative (simpler, better)
> way to make it skip FPIs.

Thanks for the update. Looking forward to seeing Thomas Munro's approach.

> FWIW one aspect of my patch worth checking would be the cost for "normal
> cases" where recovery works perfectly fine without the patch. The lookup
> in the new "history" cache might be adding measurable CPU overhead, or
> something like that. I don't think it does (and I haven't managed to
> construct such case), but if someone else verified it, that'd be good.

I also tried to construct such a case: pgbench -N at scale 1 with
frequent checkpoints (max_wal_size = 64MB). After every checkpoint, the
first change to every page writes a new FPI. However, the table is small
enough that its pages remain in shared buffers. As a result, the master
branch issues very few unnecessary prefetches (1,659 during the whole
run), so the patch provides no benefit here.

I replayed the same WAL (3 million transactions) from a base backup with
the data already in the page cache. The master branch took 2.81 seconds,
and with the patch it took 2.83 seconds (medians of 10 alternating
runs), which is within normal variation. So I did not observe any
measurable overhead either.

In another run, I added temporary counters to XLogPrefetcherHasFPI().
Out of 9.0 million block references, 5.8 million reached the check. The
quick exit from 0009 returned early for 5.3 million of those, and the
history was searched 567,000 times, which is 6.3% of all block references.

Best regards
Jan

--
Jan Nidzwetzki
PlanetScale