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 1jKC7I-0002Hp-82 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2020 02:31:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jKC7G-0003sh-Ky for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2020 02:31:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jKC7G-0003sZ-E6 for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2020 02:31:30 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jKC7E-0001Ej-6M for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2020 02:31:30 +0000 Received: from hnk.local (p2421237-ipbf2725funabasi.chiba.ocn.ne.jp [122.24.33.237]) by oss.nttdata.com (Postfix) with ESMTPSA id 5D064602EC; Fri, 3 Apr 2020 11:31:21 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.2 at oss.nttdata.com Subject: Re: BUG #16109: Postgres planning time is high across version (Expose buffer usage during planning in EXPLAIN) From: Fujii Masao To: Julien Rouhaud Cc: Justin Pryzby , Andres Freund , PostgreSQL Hackers References: <16109-26a1a88651e90608@postgresql.org> <20191112205506.rvadbx2dnku3paaw@alap3.anarazel.de> <20200124055534.GM13621@telsasoft.com> <20200331013146.GA14618@telsasoft.com> <7bdd1e99-335f-a24a-ffbd-8a578a761970@oss.nttdata.com> <045faedf-108d-26e6-7307-ab1ac2d64624@oss.nttdata.com> <20200402060154.gylqmvwdbes5s5ni@nol> <0abcbb8f-5b96-da04-ad7d-b84c36d09dd0@oss.nttdata.com> Message-ID: <1ee339d1-790f-a0a9-38f8-99d4e70630d2@oss.nttdata.com> Date: Fri, 3 Apr 2020 11:31:20 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <0abcbb8f-5b96-da04-ad7d-b84c36d09dd0@oss.nttdata.com> 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/04/02 15:52, Fujii Masao wrote: > > > On 2020/04/02 15:01, Julien Rouhaud wrote: >> On Thu, Apr 02, 2020 at 01:05:56PM +0900, Fujii Masao wrote: >>> >>> >>> On 2020/04/02 3:47, Julien Rouhaud wrote: >>>> On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao wrote: >>>>> >>>>> >>>>> On 2020/03/31 10:31, Justin Pryzby wrote: >>>>>> On Wed, Jan 29, 2020 at 12:15:59PM +0100, Julien Rouhaud wrote: >>>>>>> Rebase due to conflict with 3ec20c7091e97. >>>>>> >>>>>> This is failing to apply probably since 4a539a25ebfc48329fd656a95f3c1eb2cda38af3. >>>>>> Could you rebase?   (Also, not sure if this can be set as RFC?) >>>>> >>>>> I updated the patch. Attached. >>>> >>>> Thanks a lot!  I'm sorry I missed Justin's ping, and it I just >>>> realized that my cron job that used to warn me about cfbot failure was >>>> broken :( >>>> >>>>> +/* Compute the difference between two BufferUsage */ >>>>> +BufferUsage >>>>> +ComputeBufferCounters(BufferUsage *start, BufferUsage *stop) >>>>> >>>>> Since BufferUsageAccumDiff() was exported, ComputeBufferCounters() is >>>>> no longer necessary. In the patched version, BufferUsageAccumDiff() is >>>>> used to calculate the difference of buffer usage. >>>> >>>> Indeed, exposing BufferUsageAccumDiff wa definitely a good thing! >>>> >>>>> +       if (es->summary && (planduration || es->buffers)) >>>>> +               ExplainOpenGroup("Planning", "Planning", true, es); >>>>> >>>>> Isn't it more appropriate to check "bufusage" instead of "es->buffers" here? >>>>> The patch changes the code so that "bufusage" is checked. >>>> >>>> AFAICS not unless ExplainOneQuery is also changed to pass a NULL >>>> pointer if the BUFFER option wasn't provided (and maybe also >>>> optionally skip the planning buffer computation).  With this version >>>> you now get: >>>> >>>> =# explain (analyze, buffers off) update t1 set id = id; >>>>                                                 QUERY PLAN >>>> ------------------------------------------------------------------------------------------------------- >>>>    Update on t1  (cost=0.00..22.70 rows=1270 width=42) (actual >>>> time=0.170..0.170 rows=0 loops=1) >>>>      ->  Seq Scan on t1  (cost=0.00..22.70 rows=1270 width=42) (actual >>>> time=0.050..0.054 rows=1 loops=1) >>>>    Planning Time: 1.461 ms >>>>      Buffers: shared hit=25 >>>>    Execution Time: 1.071 ms >>>> (5 rows) >>>> >>>> which seems wrong to me. >>>> >>>> I reused the es->buffers to avoid having needing something like: >>> >>> Yes, you're right! So I updated the patch as you suggested. >>> Attached is the updated version of the patch. >>> Thanks for the review! >> >> >> Thanks a lot, it all looks good to me! > > Thanks! Barring any objection, I will commit the latest version of the patch. Pushed! Thanks a lot!! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION