On Tue, Apr 20, 2010 at 11:09 PM, Mark Kirkwood
> Robert Haas wrote:
>> So, does anyone have a few cycles to test this out? We are down to
>> handful of remaining open items, so getting this tested and committed
>> sooner = beta sooner.
> I did some testing of this patch (v2). Unfortunately I don't have access to
> hardware capable of doing tests at the same scale as Erik used. However I
> was still able to show a consistent difference (I think) between standby
> performance with and without the patch applied.
> host: 2.7 Ghz dual core amd64 with 4G ram and 1 sata drive,
> code: cvs head from 2010-04-14.
> pgbench: scale=100, 4 clients, 10000 (select) transactions each.
> Master performance (with and without patch applied ):
> tps = 10903.612340 - 14070.109951 (including connections establishing)
> Standby performance without patch (:
> tps = 8288.119913 - 9722.245178 (including connections establishing)
> Standby performance with patch applied:
> tps = 11592.922637 - 14065.553214 (including connections establishing)
> I performed 8 runs of each, and results would start at the low range and
> climb up to the high one, where they would stabilize. In between runs I
> cleared the os buffer cache and (partially) reloaded it by selecting counts
> from the pgbench tables (i.e I was trying to ensure each run had the same or
> similar os cache contents).
> Overall looks like the patch gets standby read only performance close to the
> master - at least in the case where there are minimal master transactions
> being tracked by the standby (I had to leave the master idle whilst running
> the standby case, as they shared the machine). Hope this info is useful.
Thanks, that sounds promising.
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2010-04-21 04:14:33|
|Subject: Re: Thoughts on pg_hba.conf rejection|
|Previous:||From: Tom Lane||Date: 2010-04-21 03:33:19|
|Subject: Re: Should database = all in pg_hba.conf match a replication connection? |