On Fri, May 13, 2016 at 1:43 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-05-13 10:20:04 -0400, Robert Haas wrote: >> On Fri, May 13, 2016 at 7:08 AM, Ashutosh Sharma <ashu.coe...@gmail.com> >> wrote: >> > Following are the performance results for read write test observed with >> > different numbers of "backend_flush_after". >> > >> > 1) backend_flush_after = 256kb (32*8kb), tps = 10841.178815 >> > 2) backend_flush_after = 512kb (64*8kb), tps = 11098.702707 >> > 3) backend_flush_after = 1MB (128*8kb), tps = 11434.964545 >> > 4) backend_flush_after = 2MB (256*8kb), tps = 13477.089417 >> >> So even at 2MB we don't come close to recovering all of the lost >> performance. Can you please test these three scenarios? >> >> 1. Default settings for *_flush_after >> 2. backend_flush_after=0, rest defaults >> 3. backend_flush_after=0, bgwriter_flush_after=0, >> wal_writer_flush_after=0, checkpoint_flush_after=0 > > 4) 1) + a shared_buffers setting appropriate to the workload. > > > I just want to emphasize what we're discussing here is a bit of an > extreme setup. A workload that's bigger than shared buffers, but smaller > than the OS's cache size; with a noticeable likelihood of rewriting > individual OS page cache pages within 30s.
You're just describing pgbench with a scale factor too large to fit in shared_buffers. I think it's unfair to paint that as some kind of niche use case. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
