Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Sun, Nov 13, 2016 at 1:23 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Mon, Nov 7, 2016 at 7:03 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>> On Tue, Nov 8, 2016 at 5:12 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> > On Mon, Nov 7, 2016 at 5:55 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
>> > wrote:
>> >>
>> >>
>> >> Isn't it somewhat strange that writes are showing big win whereas
>> >> reads doesn't show much win?
>> >
>> >
>> > I don't find that unusual, and have seen the same thing on Linux.
>> >
>> > With small shared_buffers, you are constantly throwing dirty buffers at
>> > the
>> > kernel in no particular order, and the kernel does a poor job of
>> > predicting
>> > when the same buffer will be dirtied repeatedly and only needs the final
>> > version of the data actually written to disk.
>> >
>>
>> Okay and I think partially it might be because we don't have writeback
>> optimization (done in 9.6) for Windows.
>
>
> Is the writeback optimization the introduction of checkpoint_flush_after, or
> is it something else?
>

Yes.

> If it is checkpoint_flush_after, then I don't think that that is related.
> In fact, they operate in opposite directions. The writeback optimization
> forces the kernel to be more eager about writing out dirty data, so it
> doesn't have a giant pile of it when the fsyncs comes at the end of the
> checkpoint. Using a large shared_buffers forces it to be less eager, by not
> turning the dirty buffers over to the kernel as often.
>

Okay, I got your point.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com