V3 of PITR performance improvement for 8.4 (WIP)

Started by Koichi Suzukiover 17 years ago2 messageshackers
Jump to latest
#1Koichi Suzuki
koichi.szk@gmail.com

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.

Still need some more work for the following:

1) Integrate with sync.rep's wal-receiver part,
2) fix to deal with WAL segment change.

V3 is posted for pre-review purpose and V4 will be posted at the
beginning of January.

Regards;

--
------
Koichi Suzuki

Attachments:

readahead-20081226.patchtext/x-diff; name=readahead-20081226.patchDownload+1276-87
#2Bruce Momjian
bruce@momjian.us
In reply to: Koichi Suzuki (#1)
Re: V3 of PITR performance improvement for 8.4 (WIP)

"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