From: | Jim Mlodgenski <jimmy76(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: testing HS/SR - 1 vs 2 performance |
Date: | 2010-04-12 12:32:39 |
Message-ID: | k2vdd92004a1004120532n34483390gee7dcb75546aa626@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 12, 2010 at 7:07 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Apr 12, 2010 at 5:06 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Sat, Apr 10, 2010 at 8:23 AM, Erik Rijkers <er(at)xs4all(dot)nl> wrote:
>>> I understand that in the scale=1000 case, there is a huge
>>> cache effect, but why doesn't that apply to the pgbench runs
>>> against the standby? (and for the scale=10_000 case the
>>> differences are still rather large)
>>
>> I guess that this performance degradation happened because a number of
>> buffer replacements caused UpdateMinRecoveryPoint() often. So I think
>> increasing shared_buffers would improve the performance significantly.
>
> I think we need to investigate this more. It's not going to look good
> for the project if people find that a hot standby server runs two
> orders of magnitude slower than the primary.
As a data point, I did a read only pgbench test and found that the
standby runs about 15% slower than the primary with identical hardware
and configs.
>
> ...Robert
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
--
Jim Mlodgenski
EnterpriseDB (http://www.enterprisedb.com)
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2010-04-12 12:39:37 | Re: Streaming replication and a disk full in primary |
Previous Message | Erik Rijkers | 2010-04-12 12:22:41 | Re: testing HS/SR - 1 vs 2 performance |