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.
Setup:
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.
Results:
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.
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
