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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
