Re: V4 of PITR performance improvement for 8.4

Hi,

This is also a reply to your latest post. I'm replying to the older
one because I need original text.

2009/1/26 Koichi Suzuki <koichi(dot)szk(at)gmail(dot)com>:
> Hi,
>
> It's simply because we should not refer to system catalog during the recovery.

This is the reason why I didn't use PrefetchBuffer(). Prefetch
buffer goes to the system catalog which we should not read during the
recovery.
I added a code to prefetch needed page without referring to the system catalog.

As you pointed out, it has nothing to do with the prefetch itself.

>
> 2009/1/25 Gregory Stark <stark(at)enterprisedb(dot)com>:
>>
>> Koichi Suzuki <koichi(dot)szk(at)gmail(dot)com> writes:
>>
>>> Please find enclosed 2nd patch of pg_readahead which include a patch
>>> to bufer manager to skip prefetch of pages already in shared buffer.
>>
>> I'm a bit confused by this comment. PrefetchBuffer already checks if the page
>> is in shared buffers.
>>
>> What is tricky to avoid is prefetching the same page twice -- since the first
>> prefetch doesn't actually put it in shared buffers there's no way to avoid
>> prefetching it again unless you keep some kind of hash of recently prefetched
>> buffers.
>>
>> For the index scan case I'm debating about whether to add such a cache
>> directly to PrefetchBuffer -- in which case it would remember if some other
>> scan prefetched the same buffer -- or to keep it in the index scan code.

I also think this could be additional feature of prefetch. On the
other hand, if some page is not on the shared buffer and on kernel's
cache, whichi should be the case we should avoid pfefetch,
posix_fadvise() will not read from the disk and the duration for this
call will be very very small. So for the time being, I think this
can be acceptable.

>>
>> --
>> Gregory Stark
>> EnterpriseDB http://www.enterprisedb.com
>> Ask me about EnterpriseDB's On-Demand Production Tuning
>>
>
>
>
> --
> ------
> Koichi Suzuki
>
--
------
Koichi Suzuki