"Koichi Suzuki" <koichi....@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
