Re: Performance degradation in commit ac1d794
От | Tom Lane |
---|---|
Тема | Re: Performance degradation in commit ac1d794 |
Дата | |
Msg-id | 14760.1464747809@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Performance degradation in commit ac1d794 (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Performance degradation in commit ac1d794
|
Список | pgsql-hackers |
Noah Misch <noah@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
В списке pgsql-hackers по дате отправления: