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 1jofZE-0003oZ-3G for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2020 04:02:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jofZD-0003ER-03 for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jun 2020 04:02:19 +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 1jofZC-0003EK-PE for pgsql-hackers@lists.postgresql.org; Fri, 26 Jun 2020 04:02:18 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jofZ9-0002eC-H6 for pgsql-hackers@postgresql.org; Fri, 26 Jun 2020 04:02:18 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1jofZ4-0002w9-B8; Fri, 26 Jun 2020 00:02:10 -0400 Date: Fri, 26 Jun 2020 00:02:10 -0400 From: Bruce Momjian To: Tomas Vondra Cc: Robert Haas , Andres Freund , David Rowley , Jeff Davis , Justin Pryzby , Melanie Plageman , "pgsql-hackers@postgresql.org" Subject: Re: Default setting for enable_hashagg_disk Message-ID: <20200626040210.GA13963@momjian.us> References: <20200624090628.GA19640@momjian.us> <20200624171203.GB17842@momjian.us> <20200624191900.t4sbfk236gndwoa3@alap3.anarazel.de> <20200624231810.GB13627@momjian.us> <20200624233837.GA21436@momjian.us> <20200625171756.GB12486@momjian.us> <20200625235357.udlest4k6i2uekui@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200625235357.udlest4k6i2uekui@development> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Jun 26, 2020 at 01:53:57AM +0200, Tomas Vondra wrote: > I'm not saying it's not beneficial to use different limits for different > nodes. Some nodes are less sensitive to the size (e.g. sorting often > gets faster with smaller work_mem). But I think we should instead have a > per-session limit, and the planner should "distribute" the memory to > different nodes. It's a hard problem, of course. Yeah, I am actually confused why we haven't developed a global memory allocation strategy and continue to use per-session work_mem. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee