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 1m6c0M-0005mX-Hg for pgsql-performance@arkaria.postgresql.org; Thu, 22 Jul 2021 16:57:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m6c0L-00043t-FY for pgsql-performance@arkaria.postgresql.org; Thu, 22 Jul 2021 16:57:01 +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 1m6c0L-000411-71 for pgsql-performance@lists.postgresql.org; Thu, 22 Jul 2021 16:57:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m6c0I-0001Ez-H0 for pgsql-performance@postgresql.org; Thu, 22 Jul 2021 16:57:00 +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 16MGurOX788608; Thu, 22 Jul 2021 12:56:53 -0400 From: Tom Lane To: Justin Pryzby cc: Peter Geoghegan , David Rowley , "ldh@laurent-hasson.com" , "pgsql-performance@postgresql.org" Subject: Re: Big performance slowdown from 11.2 to 13.3 In-reply-to: <20210722164127.GI19620@telsasoft.com> References: <784576.1626968702@sss.pgh.pa.us> <785218.1626969409@sss.pgh.pa.us> <786600.1626970898@sss.pgh.pa.us> <20210722164127.GI19620@telsasoft.com> Comments: In-reply-to Justin Pryzby message dated "Thu, 22 Jul 2021 11:41:27 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <788606.1626973012.1@sss.pgh.pa.us> Date: Thu, 22 Jul 2021 12:56:53 -0400 Message-ID: <788607.1626973013@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Justin Pryzby writes: > Oh. So the problem seems to be that: > 1) In v12, HashAgg now obeyes work_mem*hash_mem_multiplier; > 2) Under windows, work_mem is limited to 2GB. And more to the point, work_mem*hash_mem_multiplier is *also* limited to 2GB. We didn't think that through very carefully. The point of the hash_mem_multiplier feature was to allow hash aggregation to still consume more than the work_mem limit, but we failed to free it from this 2GB limit. You're right though that this is Windows-only; on machines with 64-bit "long" there's less of a problem. regards, tom lane