Re: V2 of PITR performance improvement for 8.4

Поиск
Список
Период
Сортировка
От Koichi Suzuki
Тема Re: V2 of PITR performance improvement for 8.4
Дата
Msg-id a778a7260812072154y5a14ecfewde9bdce1b3221765@mail.gmail.com
обсуждение исходный текст
Ответ на Re: V2 of PITR performance improvement for 8.4  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: V2 of PITR performance improvement for 8.4  ("Fujii Masao" <masao.fujii@gmail.com>)
Список pgsql-hackers
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.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Robert Haas"
Дата:
Сообщение: Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine
Следующее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: visibility maps and heap_prune