Noah Misch <n...@leadboat.com> writes: > On Tue, May 31, 2016 at 10:09:05PM -0400, Robert Haas wrote: >> What I *think* is going on here is: >> - ac1d794 lowered performance >> - backend_flush_after with a non-zero default lowered performance with >> a vengeance >> - 98a64d0 repaired the damage done by ac1d794, or much of it, but >> Mithun couldn't see it in his benchmarks because backend_flush_after>0 >> is so bad
> Ashutosh Sharma's measurements do bolster that conclusion. >> That could be wrong, but I haven't seen any evidence that it's wrong. >> So I'm inclined to say we should just move this open item back to the >> CLOSE_WAIT list (adding a link to this email to explain why we did >> so). Does that work for you? > That works for me. Can we make a note to re-examine this after the backend_flush_after business is resolved? Or at least get Mithun to redo his benchmarks with backend_flush_after set to zero? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers