Greg Smith wrote:
> On Fri, 6 Jul 2007, Heikki Linnakangas wrote:
>
>> There's something wrong with that. The number of buffer allocations
>> shouldn't depend on the bgwriter strategy at all.
>
> I was seeing a smaller (closer to 5%) increase in buffer allocations
> switching from no background writer to using the stock one before I did
> any code tinkering, so it didn't strike me as odd. I believe it's
> related to the TPS numbers. When there are more transactions being
> executed per unit time, it's more likely the useful blocks will stay in
> memory because their usage_count is getting tickled faster, and
> therefore there's less of the most useful blocks being swapped out only
> to be re-allocated again later.
Did you run the test for a constant number of transactions? If you did,
the access pattern and the number of allocations should be *exactly* the
same with 1 client, assuming the initial state and the seed used for the
random number generator is the same.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
