On Wed, Aug 24, 2016 at 2:35 PM, Tsunakawa, Takayuki
> From: Peter Geoghegan [mailto:p...@heroku.com]
>> On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian <br...@momjian.us> wrote:
>> >> [Windows]
>> >> #clients on off
>> >> 12 29793 38169
>> >> 24 31587 87237
>> >> 48 32588 83335
>> >> 96 34261 67668
>> > This ranges from a 28% to a 97% speed improvement on Windows! Those
>> > are not typos! This is a game-changer for use of Postgres on Windows
>> > for certain workloads!
>> While I don't care all that much about performance on windows, it is a little
>> sad that it took this long to fix something so simple. Consider this
>> as a further example of our lack of concern here:
> Probably, the useful Windows Performance Toolkit, which is a counterpart of
> perf on Linux, was not available before. Maybe we can dig deeper into
> performance problems with it now.
> As a similar topic, I wonder whether the following still holds true, after
> many improvements on shared buffer lock contention.
> "The useful range for shared_buffers on Windows systems is generally
> from 64MB to 512MB."
I don't use Windows, but I have heard recently that this is still true
from someone who was testing with pgbench. He reported a dip in the
curve above 512MB.
Another database vendor recommends granting SeLockMemoryPrivilege so
that it can use large pages on Windows when using several GB of buffer
pool. I wonder if that might help Postgres on Windows. This could be
useful as a starting point to test that theory:
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: