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'" <bruce@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