| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Jeff Trout <threshar(at)threshar(dot)is-a-geek(dot)com>, pgsql-hackers(at)postgresql(dot)org, Koichi Suzuki <suzuki(dot)koichi(at)oss(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: [GENERAL] Slow PITR restore |
| Date: | 2007-12-13 22:10:44 |
| Message-ID: | 21293.1197583844@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Koichi showed me & Simon graphs of DBT-2 runs in their test lab back in
> May. They had setup two identical systems, one running the benchmark,
> and another one as a warm stand-by. The stand-by couldn't keep up; it
> couldn't replay the WAL as quickly as the primary server produced it.
> IIRC, replaying WAL generated in a 1h benchmark run took 6 hours.
[ shrug... ] This is not consistent with my experience. I can't help
suspecting misconfiguration; perhaps shared_buffers much smaller on the
backup, for example.
> One KISS approach would be to just do full page writes more often. It
> would obviously bloat the WAL, but it would make the replay faster.
... at the cost of making the primary lots slower.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-12-13 22:16:39 | Re: [GENERAL] Slow PITR restore |
| Previous Message | Heikki Linnakangas | 2007-12-13 21:57:29 | Re: [GENERAL] Slow PITR restore |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-12-13 22:16:39 | Re: [GENERAL] Slow PITR restore |
| Previous Message | Heikki Linnakangas | 2007-12-13 21:57:29 | Re: [GENERAL] Slow PITR restore |