Re: patch: improve SLRU replacement algorithm

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