On 09/19/2017 09:32 AM, 'Bruce Momjian' wrote:
On Tue, Sep 19, 2017 at 12:30:01PM -0400, Tom Lane wrote:
"'Bruce Momjian'" <br...@momjian.us> writes:
On Tue, Sep 19, 2017 at 12:22:39PM -0400, Tom Lane wrote:
We don't normally release-note documentation changes. If this
wasn't purely a documentation change, then I was probably in error
to decide it didn't need to be in the notes.
It was purely a documentation change, but it was a documented change in a
long-standing and popular practice of not using too many shared buffers
on Windows, so I thought it wise to add it.
Well, if the intent of the note was to encourage people to raise
shared_buffers, it didn't do a very good job of that as written,
because I sure didn't understand it that way.
Do you have any suggestions since it is not a code change that I can
point to? My guess is that the limitation was removed years ago, but we
only found out recently.
My guess is that the limitation was removed as of 9.3 with the work Haas
did with shared buffers. Thus, yes it was years ago. I think that
listing it regardless of the documentation change could be useful.
Something like:
"""
Better support for large shared_buffers configurations including the
Windows platform. Users are encouraged to review their shared_buffer
settings against the size of their active data set and reconfigure
appropriately.
"""
It is pretty much practitioner given that if your active data set can
fit in shared_buffers and you aren't going to adversely affect the
ability for the system to operate, that you should configure a high
setting. I have seen settings as much as 96GB doing wonderfully in
production.
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
***** Unless otherwise stated, opinions are my own. *****
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
