"Koichi Suzuki" <koichi.szk@gmail.com> writes:
> This is the V3 of PITR performance improvement (readahead). The
> change of the code is as follows:
>
> 1) Now readahead is integrated into the core so that it can deal with
> sync.rep's log shipping.
> 2) posix_fadvise() call was integrated with Greg Stark's patch.
Wow, this is really cool. It integrates into core the readahead of WAL records
using a new RM method for each WAL type. That's great.
I haven't looked closely yet, I assume this avoids the code duplication? I did
notice there's a whole queue data structure for planning which blocks to
prefetch. Why is that necessary instead of just keeping a count of how many
blocks have been prefetched? Does it help avoid prefetching the same blocks
repeatedly?
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning
