On Sun, Nov 13, 2016 at 1:23 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Mon, Nov 7, 2016 at 7:03 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> >> On Tue, Nov 8, 2016 at 5:12 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> > On Mon, Nov 7, 2016 at 5:55 AM, Amit Kapila <amit.kapil...@gmail.com> >> > wrote: >> >> >> >> >> >> 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. > > > Is the writeback optimization the introduction of checkpoint_flush_after, or > is it something else? >
Yes. > If it is checkpoint_flush_after, then I don't think that that is related. > In fact, they operate in opposite directions. The writeback optimization > forces the kernel to be more eager about writing out dirty data, so it > doesn't have a giant pile of it when the fsyncs comes at the end of the > checkpoint. Using a large shared_buffers forces it to be less eager, by not > turning the dirty buffers over to the kernel as often. > Okay, I got your point. -- 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
