Re: V2 of PITR performance improvement for 8.4

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