Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-26 Thread Koichi Suzuki
I'm now writing v3 patch of PITR improvement, to work with sync.rep and Hot Standby.Would like to change the thread. 2008/12/12 Pavan Deolasee pavan.deola...@gmail.com: On Fri, Dec 12, 2008 at 9:08 AM, Koichi Suzuki koichi@gmail.com wrote: Hmmm, it's really like pg_readahead needs to

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-11 Thread Koichi Suzuki
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

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-11 Thread Pavan Deolasee
On Fri, Dec 12, 2008 at 9:08 AM, Koichi Suzuki koichi@gmail.com wrote: 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. Yes, I think it's best to have it in core. I would actually combine it with the other idea

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-08 Thread Fujii Masao
Hi, On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki [EMAIL PROTECTED] 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

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-07 Thread Koichi Suzuki
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

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-04 Thread Simon Riggs
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.

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-04 Thread Fujii Masao
Hi, On Thu, Dec 4, 2008 at 6:11 PM, Simon Riggs [EMAIL PROTECTED] wrote: 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

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-03 Thread Koichi Suzuki
Agreed. I borrowed WAL parsing code from XLogdump and I think WAL parsing should be another candidate. 2008/12/3 Fujii Masao [EMAIL PROTECTED]: Hi, On Thu, Nov 27, 2008 at 9:04 PM, Koichi Suzuki [EMAIL PROTECTED] wrote: Please find enclosed a revised version of pg_readahead and a patch to

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-02 Thread Koichi Suzuki
Hi, As to checkpoint timeout, yes, this measurement is hard for FPW=on case. I'll do the similar measurement for checkpoint timeout = 5min and post the result. I expect that the recoevry time will be almost the same in the case FPW=on, lesslog=yes and prefetpch = yes. 2008/12/2 Simon Riggs

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-02 Thread Fujii Masao
Hi, On Thu, Nov 27, 2008 at 9:04 PM, Koichi Suzuki [EMAIL PROTECTED] wrote: Please find enclosed a revised version of pg_readahead and a patch to invoke pg_readahead. Some similar functions are in xlog.c and pg_readahead.c (for example, RecordIsValid). I think that we should unify them as a

Re: [HACKERS] V2 of PITR performance improvement for 8.4

2008-12-01 Thread Simon Riggs
On Thu, 2008-11-27 at 21:04 +0900, Koichi Suzuki wrote: We ran the benchmark for on hour with chekpoint timeout 30min and completion_target 0.5. Then, collected all the archive log and run PITR. --+++--- WAL conditions