| Lists: | pgsql-hackers |
|---|
| From: | "Koichi Suzuki" <koichi(dot)szk(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | V3 of PITR performance improvement for 8.4 (WIP) |
| Date: | 2008-12-26 08:11:22 |
| Message-ID: | a778a7260812260011s3bfcb6e2p4b7d9142aa593477@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| readahead-20081226.patch | text/x-diff | 51.9 KB |
| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Koichi Suzuki" <koichi(dot)szk(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: V3 of PITR performance improvement for 8.4 (WIP) |
| Date: | 2008-12-27 06:04:45 |
| Message-ID: | 87hc4qrw5e.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
"Koichi Suzuki" <koichi(dot)szk(at)gmail(dot)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