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

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?

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.

> However, still the broader
> question stands that whether above data is sufficient to say that we
> can recommend the settings of shared_buffers on Windows similar to
> Linux?
>

We do have evidence that the old advice is out of date. So I think we
should just remove it. We have no evidence that the optimal Windows
setting on modern Windows is the same as it is for Linux, but also no
evidence that it is not the same.

Cheers,

Jeff