On Wed, Apr 4, 2012 at 8:00 AM, Robert Haas <robertmh...@gmail.com> wrote: > There's some apparent regression on the single-client test, but I'm > inclined to think that's a testing artifact of some kind and also > probably not very important. It would be worth paying a small price > in throughput to avoid many-second entire-database stalls, but on this > test throughput actually goes up in all cases other than a single > client; and it's hard to take the single client case seriously as a > regression anyway because if there's only one thing running, the only > effect of this patch is to slightly increase the amount of CPU effort > that we spend before replacement the same buffer we would have > replaced anyway. There's no way that's enough to cut 3% off > performance; I think the explanation must be something like, say, > autovacuum runs a bit faster because it doesn't hang as much, but then > that triggers a checkpoint sooner; or something's shuffled itself > around across cache lines in a way that works out a little worse; or > maybe it's just that the patched code was tested second.
I reran the single client tests and this time got: m01 tps = 1357.485132 (including connections establishing) m01 tps = 1425.967027 (including connections establishing) m01 tps = 1381.468519 (including connections establishing) s01 tps = 1411.590074 (including connections establishing) s01 tps = 1374.938182 (including connections establishing) s01 tps = 1402.680618 (including connections establishing) ...which seems like ample evidence that there's no real regression here, if anyone was still worried. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers