>> > 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?
Based on this optimization we might want to keep the text that says large shared buffers on Windows aren't as effective perhaps, and just remove the sentence that explicitly says don't go over 512MB?