On Sat, Nov 12, 2016 at 11:00 PM, Magnus Hagander <mag...@hagander.net> wrote: > On Sat, Nov 12, 2016 at 4:03 AM, Amit Kapila <amit.kapil...@gmail.com> > wrote: >> >> On Fri, Nov 11, 2016 at 3:01 PM, Magnus Hagander <mag...@hagander.net> >> wrote: >> >> > Based on this optimization we might want to keep the text that says >> >> > large >> >> > shared buffers on Windows aren't as effective perhaps, >> >> Sounds sensible or may add a line to say why it isn't as effective as on >> Linux. > > > Do we actually know *why*? >
No, I have never investigated it for Windows. I am just telling based on results reported in this thread. I have seen that there is a noticeable difference of read-only performance when data fits in shared buffers as compared to when it doesn't fit on Linux systems. >> >> Right, but for other platforms, the recommendation seems to be 25% of >> RAM, can we safely say that for Windows as well? As per test results >> in this thread, it seems the read-write performance degrades when >> shared buffers have increased from 12.5 to 25%. I think as the test >> is done for a short duration so that degradation could be just a run >> to run to run variation, that's why I suggested doing few more tests. > > > We talk about 25%, but only up to a certain size. It's suggested as a > starting point. The 25% value us probably good as a starting point, as it's > recommended, but not as a "recommended setting". I'm fine with doing > something similar for Windows -- say "10-15% as a starting point, but you > have to check with your workload" kind of statements. > Okay, not a problem. However, I am not sure the results in this thread are sufficient proof as for read-only tests, there is no noticeable win by increasing shared buffers and read-write tests seems to be quite short (60 seconds) to rely on it. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
