From: "Kevin Grittner" on
"Huda Booley (huda(a)careerjunction.co.za)"
<Huda(a)careerjunction.co.za> wrote:

> These get copied to the standby so its all there, just not being
> applied fast enough.

If the files are there and are not applying fast enough, it's
probably because on the source machine you can have multiple
connections submitting data modifications, keeping multiple CPUs and
spindles busy all at the same time. When playing back the WAL files
on the warm standby, you have one connection which has a harder time
keeping a lot of resources busy.

I think I have some recall of improvements to that in the 8.4
release, so an upgrade might help. Other than that, I think it's
mostly a matter of your hardware and OS. Make sure you have a RAID
controller with battery backed cache configured for write-back,
spread the database across as many spindles as you can, don't worry
so much about how *many* CPUs you have as how *fast* they are.

I've never actually had this problem, so take my advice on it with
a grain of salt.

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Greg Stark on
On Fri, Jan 22, 2010 at 2:37 PM, Kevin Grittner
<Kevin.Grittner(a)wicourts.gov> wrote:
>
> I think I have some recall of improvements to that in the 8.4
> release, so an upgrade might help.

There was a standalone program which you can call from your recovery
script to prefetch the blocks needed to replay the next log file
before starting to apply it. I find this message but there may be a
more recent version if you search:
http://archives.postgresql.org/pgsql-hackers/2008-11/msg01807.php

Otherwise I think there were some performance improvements to replay
but I don't recall which versions which improvements were in.

--
greg

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers