Re: V4 of PITR performance improvement for 8.4

From: Koichi Suzuki <koichi(dot)szk(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: V4 of PITR performance improvement for 8.4
Date: 2009-02-25 20:03:22
Message-ID: a778a7260902251203l50700c0cs4b82b4fe0675175@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

My reply to Gregory's comment didn't have any objections. I believe,
as I posted to Wiki page, latest posted patch is okay and waiting for
review.

2009/2/24 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Sun, Jan 25, 2009 at 7:15 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>> 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.
>
> Has this issue been resolved?  Does this patch need more review?
> Because if so, I'm guessing it needs to happen RSN.
>
> ...Robert
>

--
------
Koichi Suzuki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-02-25 20:14:39 Re: Synchronous replication & Hot standby patches
Previous Message Teodor Sigaev 2009-02-25 18:44:13 Re: regression test crashes at tsearch