Re: V2 of PITR performance improvement for 8.4

Hmmm,  it's really like pg_readahead needs to be included in the core.  I don't think it's a big work and will try to
dothis.
 

2008/12/9 Fujii Masao <masao.fujii@gmail.com>:
> Hi,
>
> On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki <koichi.szk@gmail.com> wrote:
>> I understood your point.  In the case of synchronous replication,
>> because slave fails over when master crashes,  there're no need to
>> leave FPW from the beginning.
>>
>> In this case, only prefetch will work.   Fujii's code at the slave
>> looks very similar to pg_standby and pg_readahead will help in this
>> case with no modification.
>
> As the result of discussion, I will change the way to recover on the standby;
> we don't use PITR for the WAL which walreceiver received, instead, startup
> process read it by *record* from pg_xlog and redo. So, I'm afraid that
> synchronous replication doesn't match well with pg_readahead.
>
> Regards,
>
>>
>> 2008/12/4 Simon Riggs <simon@2ndquadrant.com>:
>>>
>>> On Wed, 2008-12-03 at 14:22 +0900, Koichi Suzuki wrote:
>>>
>>>> > There's clearly a huge gain using prefetch, when we have
>>>> > full_page_writes = off. But that does make me think: Why do we need
>>>> > prefetch at all if we use full page writes? There's nothing to prefetch
>>>> > if we can keep it in cache.
>>>>
>>>> Agreed.   This is why I proposed prefetch optional through GUC.
>>>>
>>>> > So I'm wondering if we only need prefetch because we're using lesslog?
>>>> >
>>>> > If we integrated lesslog better into the new replication would we be
>>>> > able to forget about doing the prefetch altogether?
>>>>
>>>> In the case of lesslog, almost all the FPW is replaced with
>>>> corresponding incremental log and recovery takes longer.   Prefetch
>>>> dramatically improve this, as you will see in the above result.    To
>>>> improve recovery time with FPW=off or FPW=on and lesslog=yes, we need
>>>> prefetch.
>>>
>>> It does sound like it is needed, yes. But if you look at the
>>> architecture of synchronous replication in 8.4 then I don't think it
>>> makes sense any more. It would be very useful for the architecture we
>>> had in 8.3, but that time has gone.
>>>
>>> If we have FPW=on on primary then we will stream WAL with FPW to
>>> standby. There seems little point removing it *after* it has been sent,
>>> then putting it back again before we recover, especially when it causes
>>> a drop in performance that then needs to be fixed (by this patch).
>>>
>>> pg_lesslog allowed us to write FPW to disk, yet send WAL without FPW.
>>>
>>> So if we find a way of streaming WAL without FPW then this patch makes
>>> sense, but not until then. So far many people have argued in favour of
>>> using FPW=on, which was the whole point of pg_lesslog. Are we now saying
>>> that we would run the primary with FPW=off?
>>>
>>> --
>>>  Simon Riggs           www.2ndQuadrant.com
>>>  PostgreSQL Training, Services and Support
>>>
>>>
>>
>>
>>
>> --
>> ------
>> Koichi Suzuki
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>>
>
>
>
> --
> Fujii Masao
> NIPPON TELEGRAPH AND TELEPHONE CORPORATION
> NTT Open Source Software Center
>



-- 
------
Koichi Suzuki