On Wed, Apr 4, 2012 at 8:00 AM, Robert Haas <robertmhaas@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
