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

On Sat, Nov 12, 2016 at 11:00 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Sat, Nov 12, 2016 at 4:03 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
>>
>> On Fri, Nov 11, 2016 at 3:01 PM, Magnus Hagander <magnus(at)hagander(dot)net>
>> wrote:
>> >> > Based on this optimization we might want to keep the text that says
>> >> > large
>> >> > shared buffers on Windows aren't as effective perhaps,
>>
>> Sounds sensible or may add a line to say why it isn't as effective as on
>> Linux.
>
>
> Do we actually know *why*?
>

No, I have never investigated it for Windows. I am just telling based
on results reported in this thread. I have seen that there is a
noticeable difference of read-only performance when data fits in
shared buffers as compared to when it doesn't fit on Linux systems.

>>
>> Right, but for other platforms, the recommendation seems to be 25% of
>> RAM, can we safely say that for Windows as well? As per test results
>> in this thread, it seems the read-write performance degrades when
>> shared buffers have increased from 12.5 to 25%. I think as the test
>> is done for a short duration so that degradation could be just a run
>> to run to run variation, that's why I suggested doing few more tests.
>
>
> We talk about 25%, but only up to a certain size. It's suggested as a
> starting point. The 25% value us probably good as a starting point, as it's
> recommended, but not as a "recommended setting". I'm fine with doing
> something similar for Windows -- say "10-15% as a starting point, but you
> have to check with your workload" kind of statements.
>

Okay, not a problem. However, I am not sure the results in this
thread are sufficient proof as for read-only tests, there is no
noticeable win by increasing shared buffers and read-write tests seems
to be quite short (60 seconds) to rely on it.

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