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 |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2008-12-27 12:28:52 | pg_start_backup without checkpoint patch (a part of Synch Rep) |
Previous Message | Erik Rijkers | 2008-12-27 00:59:56 | pg_restore --clean text |