Re: V2 of PITR performance improvement for 8.4

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