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

On Tue, Nov 8, 2016 at 5:12 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Mon, Nov 7, 2016 at 5:55 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Tue, Sep 20, 2016 at 8:15 AM, Tsunakawa, Takayuki
>> <tsunakawa.takay@jp.fujitsu.com> wrote:

>> > I ran read-only and read-write modes of pgbench, and could not see any
>> > apparent decrease in performance when I increased shared_buffers.  The
>> > scaling factor is 200, where the database size is roughly 3GB.  I ran the
>> > benchmark on my Windows 10 PC with 6 CPU cores and 16GB of RAM.  The
>> > database and WAL is stored on the same HDD.
>> >
>> > <<Test batch file>>
>> > @echo off
>> > for %%s in (256MB 512MB 1GB 2GB 4GB) do (
>> >   pg_ctl -w -o "-c shared_buffers=%%s" start
>> >   pgbench -c18 -j6 -T60 -S bench >> g:\b.txt 2>&1
>> >   pg_ctl -t 3600 stop
>> > )
>> >
>> > <<Select-only (with -S)>>
>> > shared_buffers  tps
>> > 256MB  63056
>> > 512MB  63918
>> > 1GB  65520
>> > 2GB  66840
>> > 4GB  68270
>> >
>> > <<Read-write (without -S)>>
>> > shared_buffers  tps
>> > 256MB  1138
>> > 512MB  1187
>> > 1GB  1571
>> > 2GB  1650
>> > 4GB  1598
>> >
>>
>> Isn't it somewhat strange that writes are showing big win whereas
>> reads doesn't show much win?
>
>
> I don't find that unusual, and have seen the same thing on Linux.
>
> With small shared_buffers, you are constantly throwing dirty buffers at the
> kernel in no particular order, and the kernel does a poor job of predicting
> when the same buffer will be dirtied repeatedly and only needs the final
> version of the data actually written to disk.
>

Okay and I think partially it might be because we don't have writeback
optimization (done in 9.6) for Windows.  However, still the broader
question stands that whether above data is sufficient to say that we
can recommend the settings of shared_buffers on Windows similar to
Linux?