On Tue, May 31, 2016 at 10:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
Ashutosh Sharma already did pretty much that test in the email to which I linked. (Ashutosh Sharma and Mithun CY work in the same office and have access to the same hardware.) -- 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
