From: | Gabi Julien <gabi(dot)julien(at)broadsign(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Subject: | Re: Fwd: Re: New 8.4 hot standby feature |
Date: | 2009-01-28 19:20:56 |
Message-ID: | 200901281420.56496.gabi.julien@broadsign.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tuesday 27 January 2009 16:25:44 you wrote:
> On Tue, 2009-01-27 at 14:28 -0500, Gabi Julien wrote:
> > Could this help? If the logs are smaller then I could potentially afford
> > shipping then at a higher frequency.
>
> See if there are times during which the recovery process isn't doing
> anything (i.e. just waiting for WAL data). If so, something like this
> might help. If it's constantly working as hard as it can, then probably
> not.
>
> An important question you should ask yourself is whether it can keep up
> in the steady state at all. If the primary is producing segments faster
> than the standby is recovering them, I don't think there's any way
> around that.
The load on the slave is close to 0 so it does not explain the speed of
recovery. Also the shipping of the 16MB WAL log takes only 1 second on the
LAN. I guess the problem is probably what Fujii Masao explained. The WAL log
shipped are not yet usable or something like that. I won't try to increase
the frequency of log shipping because of that. Also, my setting of 60 seconds
is the lowest frequency suggested by the documentation anyways.
However, I have found the v4 patch about the PITR performance improvement. I
will give it a try and report here.
I might try pg_clearxlogtail too if I have time.
>
> Regards,
> Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Sergio Borgonovo | 2009-01-28 20:14:24 | Re: very long update gin index troubles back? |
Previous Message | Alban Hertroys | 2009-01-28 18:25:09 | Re: Slow first query despite LIMIT and OFFSET clause |