On Sun, Nov 13, 2016 at 1:23 AM, Jeff Janes <[email protected]> wrote: > On Mon, Nov 7, 2016 at 7:03 PM, Amit Kapila <[email protected]> wrote: >> >> On Tue, Nov 8, 2016 at 5:12 AM, Jeff Janes <[email protected]> wrote: >> > On Mon, Nov 7, 2016 at 5:55 AM, Amit Kapila <[email protected]> >> > 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
