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 1m7iYM-0006IP-Km for pgsql-performance@arkaria.postgresql.org; Sun, 25 Jul 2021 18:08:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m7iYL-0002n1-CK for pgsql-performance@arkaria.postgresql.org; Sun, 25 Jul 2021 18:08:41 +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 1m7iYL-0002mt-4P for pgsql-performance@lists.postgresql.org; Sun, 25 Jul 2021 18:08:41 +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 1m7iYI-0000OH-UB for pgsql-performance@postgresql.org; Sun, 25 Jul 2021 18:08:40 +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 16PI8Rx8171156; Sun, 25 Jul 2021 14:08:28 -0400 From: Tom Lane To: "ldh@laurent-hasson.com" cc: Peter Geoghegan , David Rowley , 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> <732758.1626911007@sss.pgh.pa.us> <784576.1626968702@sss.pgh.pa.us> <785218.1626969409@sss.pgh.pa.us> <786600.1626970898@sss.pgh.pa.us> <787780.1626972122@sss.pgh.pa.us> Comments: In-reply-to "ldh@laurent-hasson.com" message dated "Thu, 22 Jul 2021 17:26:36 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <171154.1627236507.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Jul 2021 14:08:27 -0400 Message-ID: <171155.1627236507@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: > As a user of PG, we have taken pride in the last few years in tuning the= heck out of the system and getting great performance compared to alternat= ives like SQLServer. The customers we work with typically have data center= s and are overwhelmingly Windows shops: we won the battle to deploy a comp= lex operational system on PG vs SQLServer, but Linux vs Windows was still = a bridge too far for many. I am surprised that this limitation introduced = after V11 hasn't caused issues elsewhere though. Maybe it has, but you're the first to report the problem, or at least the first to report it with enough detail to trace the cause. I've pushed a fix that removes the artificial restriction on work_mem times hash_mem_multiplier; it will be in next month's 13.4 release. You'll still need to increase hash_mem_multiplier to get satisfactory performance on your workload, but at least it'll be possible to do that. regards, tom lane