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

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*?

> > and just remove
> >> > the
> >> > sentence that explicitly says don't go over 512MB?
> >>
>
> Have we done any windows specific optimization since it was originally
> mentioned as 512MB which indicates that we can remove it? Are you
> telling it based on results in this thread, if so, I think it is
> better to do few more tests before changing it.
>

Well, that advice goes *way* back. Many things have changed since then -
and just look at things like the updating of the stats target. For one
thing, we're in 64-bit now, not 32, for the majority of users. We reserve
the shared memory on startup which was done for address probability issues,
but may have had side effects. And *Windows itself* has changed in those 10
or so years.

I've heard it from other people as well, but this thread is definitely one
of them. I think the old truth about "never go above that" is invalid at
this point, but it may never have been valid. But I also don't think we
know what to put there instead, as a recommendation.

> >> Just removing the reference to the size would make users ask a question
> >> "What size is the effective upper limit?"
> >
> >
> > True, but that's a question for other platforms as well, isn't it?
> >
>
> 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.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/