From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bgwriter strategies |
Date: | 2007-07-06 10:55:23 |
Message-ID: | 468E1F9B.2020904@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Glaesemann | 2007-07-06 13:08:40 | Re: script binaries renaming |
Previous Message | Dave Page | 2007-07-06 10:53:17 | Re: script binaries renaming |