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 1m6Ll1-0005Hy-9z for pgsql-performance@arkaria.postgresql.org; Wed, 21 Jul 2021 23:36:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m6Ll0-00047n-9J for pgsql-performance@arkaria.postgresql.org; Wed, 21 Jul 2021 23:36:06 +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 1m6Ll0-00047f-1Z for pgsql-performance@lists.postgresql.org; Wed, 21 Jul 2021 23:36:06 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m6Lkv-0003ea-On for pgsql-performance@postgresql.org; Wed, 21 Jul 2021 23:36:05 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 16LNZv1d732368; Wed, 21 Jul 2021 19:35:57 -0400 From: Tom Lane To: "ldh@laurent-hasson.com" cc: Justin Pryzby , "pgsql-performance@postgresql.org" Subject: Re: Big performance slowdown from 11.2 to 13.3 In-reply-to: References: <20210721191528.GC19620@telsasoft.com> Comments: In-reply-to "ldh@laurent-hasson.com" message dated "Wed, 21 Jul 2021 23:19:04 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <732366.1626910557.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2021 19:35:57 -0400 Message-ID: <732367.1626910557@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "ldh@laurent-hasson.com" writes: > My apologies... I thought this is what I had attached in my original ema= il from PGADMIN. In any case, I reran from the command line and here are t= he two plans. So the pain seems to be coming in with the upper hash aggregation, which is spilling to disk because work_mem of '384MB' is nowhere near enough. The v11 explain doesn't show any batching there, which makes me suspect that it was using a larger value of work_mem. (There could also be some edge effect that is making v13 use a bit more memory for the same number of tuples, which could lead it to spill when v11 had managed to scrape by without doing so.) So the first thing I'd try is seeing if setting work_mem to 1GB or so improves matters. The other thing that's notable is that v13 has collapsed out the CTE that used to sit between the two levels of hashagg. Now I don't know of any reason that that wouldn't be a strict improvement, but if the work_mem theory doesn't pan out then that's something that'd deserve a closer look. Does marking the WITH as WITH MATERIALIZED change anything about v13's performance? regards, tom lane