Re: Bgwriter strategies

Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>>             imola-336    imola-337    imola-340
>> writes by checkpoint      38302          30410          39529
>> writes by bgwriter     350113        2205782        1418672
>> writes by backends    1834333         265755         787633
>> writes total        2222748        2501947        2245834
>> allocations        2683170        2657896        2699974
> 
>> It looks like Tom's idea is not a winner; it leads to more writes than 
>> necessary.
> 
> The incremental number of writes is not that large; only about 10% more.
> The interesting thing is that those "extra" writes must represent
> buffers that were re-touched after their usage_count went to zero, but
> before they could be recycled by the clock sweep.  While you'd certainly
> expect some of that, I'm surprised it is as much as 10%.  Maybe we need
> to play with the buffer allocation strategy some more.
> 
> The very small difference in NOTPM among the three runs says that either
> this whole area is unimportant, or DBT2 isn't a good test case for it;
> or maybe that there's something wrong with the patches?

The small difference in NOTPM is because the I/O still wasn't saturated 
even with 10% extra writes.

I ran more tests with a higher number of warehouses, and the extra 
writes start to show in the response times. See tests 341-344: 
http://community.enterprisedb.com/bgwriter/.

I scheduled a test with the moving average method as well, we'll see how 
that fares.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com