From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
cc: Robert Haas <robertmhaas@gmail.com>,
        =?utf-8?B?0JLQsNGB0LjQu9GM0LXQsiDQlNC80LjRgtGA0LjQuQ==?=
 <d.vasilyev@postgrespro.ru>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Performance degradation in commit ac1d794
In-reply-to: <20160601022005.GB596188@tornado.leadboat.com>
References: 
 <CAB-SwXZh44_2ybvS5Z67p_CDz=XFn4hNAD=CnMEF+QqkXwFrGg@mail.gmail.com>
 <20160529054052.GA497229@tornado.leadboat.com>
 <CA+TgmoaO9FhPk0ricGkKufh=Aj_LUhgwoeGJaCoPJ0S_YZm4rQ@mail.gmail.com>
 <20160601022005.GB596188@tornado.leadboat.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Tue, 31 May 2016 22:20:05 -0400"
Date: Tue, 31 May 2016 22:23:29 -0400
Message-ID: <14760.1464747809@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers