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.fu...@gmail.com>: > Hi, > > On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki <koichi....@gmail.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 <si...@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 >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
