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 do this.

2008/12/9 Fujii Masao <masao(dot)fujii(at)gmail(dot)com>:
> Hi,
>
> On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki <koichi(dot)szk(at)gmail(dot)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(at)2ndquadrant(dot)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(at)postgresql(dot)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