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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
