Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jrFdq-0001bd-28 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2020 06:57:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jrFdp-0000XY-08 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2020 06:57:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jrFdo-0000XP-P0 for pgsql-hackers@lists.postgresql.org; Fri, 03 Jul 2020 06:57:44 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jrFdm-0007tE-A9 for pgsql-hackers@postgresql.org; Fri, 03 Jul 2020 06:57:43 +0000 Received: from hnk.local (p2604028-ipngn12401funabasi.chiba.ocn.ne.jp [180.1.110.28]) by oss.nttdata.com (Postfix) with ESMTPSA id B1C286029A; Fri, 3 Jul 2020 15:57:38 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: track_planning causing performance regression To: Pavel Stehule Cc: Peter Geoghegan , Julien Rouhaud , "Tharakan, Robins" , "pgsql-hackers@postgresql.org" References: <2895b53b033c47ccb22972b589050dd9@EX13D05UWC001.ant.amazon.com> <42a13b4c-e60c-c6e7-3475-8eff8050bed4@oss.nttdata.com> From: Fujii Masao Message-ID: <646e5cae-5e8b-feaa-43dc-014bf355bf08@oss.nttdata.com> Date: Fri, 3 Jul 2020 15:57:38 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/07/03 13:05, Pavel Stehule wrote: > Hi > > pá 3. 7. 2020 v 4:39 odesílatel Fujii Masao > napsal: > > > > On 2020/07/01 7:37, Peter Geoghegan wrote: > > On Tue, Jun 30, 2020 at 6:40 AM Fujii Masao > wrote: > >> Ants and Andres suggested to replace the spinlock used in pgss_store() with > >> LWLock. I agreed with them and posted the POC patch doing that. But I think > >> the patch is an item for v14. The patch may address the reported performance > >> issue, but may cause other performance issues in other workloads. We would > >> need to measure how the patch affects the performance in various workloads. > >> It seems too late to do that at this stage of v13. Thought? > > > > I agree that it's too late for v13. > > Thanks for the comment! > > So I pushed the patch and changed default of track_planning to off. > > > Maybe there can be documented so enabling this option can have a negative impact on performance. Yes. What about adding either of the followings into the doc? Enabling this parameter may incur a noticeable performance penalty. or Enabling this parameter may incur a noticeable performance penalty, especially when a fewer kinds of queries are executed on many concurrent connections. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION