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 1lSLob-0002cU-IS for pgsql-admin@arkaria.postgresql.org; Fri, 02 Apr 2021 15:34:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lSLoa-0003y0-Hp for pgsql-admin@arkaria.postgresql.org; Fri, 02 Apr 2021 15:34:28 +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 1lSLoa-0003xt-AC for pgsql-admin@lists.postgresql.org; Fri, 02 Apr 2021 15:34:28 +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 1lSLoW-0002Sl-2o for pgsql-admin@lists.postgresql.org; Fri, 02 Apr 2021 15:34:27 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1lSLOa-0004l6-3M; Fri, 02 Apr 2021 11:07:36 -0400 Date: Fri, 2 Apr 2021 11:07:36 -0400 From: Bruce Momjian To: Laurenz Albe Cc: "Campbell, Lance" , MichaelDBA , SASIKUMAR Devaraj , "holger@jakobs.com" , "pgsql-admin@lists.postgresql.org" Subject: Re: work_mem Message-ID: <20210402150736.GD9270@momjian.us> References: <04D84259-1B75-4648-949F-78677916194E@jakobs.com> <66290583.2329958.1617367063840@mail.yahoo.com> <1654783699.2333997.1617367552583@mail.yahoo.com> <592e5895-8dbd-1a4f-a87c-af72ac8eea02@sqlexec.com> <339e1ee870881a3efaffc7ea4cddac6bc4d009cf.camel@cybertec.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <339e1ee870881a3efaffc7ea4cddac6bc4d009cf.camel@cybertec.at> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Apr 2, 2021 at 04:59:16PM +0200, Laurenz Albe wrote: > On Fri, 2021-04-02 at 13:31 +0000, Campbell, Lance wrote: > > It feels like there needs to be work_mem and work_mem_stack_size. When work memory is > > needed a process “pops” a token off of a stack. When it is done processing it “puts” > > the token back on the stack. If the stack is empty then don’t allocate memory just > > write to disk for work_mem. > > > > This does two key things: > > > > 1) It allows for a real world understanding of how much memory is really needed on a > > day to day basis. You can track how often a stack is empty. You can also look at the > > number of temp files to see when work exceeds the work_mem allocation. There is no > > “art” to setting these values. You can use logical analysis to make choices. > > > > 2) This also prevents out of memory issues. You are protecting yourself from extreme loads. > > If I get you right, you want another memory limit per session. > > I see the point, but then we wouldn't need "work_mem" any more, right? > What is the point of limiting the memory per plan node if we have an > overall limit? > > In practice, I have never had trouble with "work_mem". I usually follow > my rule of thumb: max_connections * work_mem + shared_buffers < RAM > > While some backend may need more, many will need less. Only bitmaps, hashes > and sorts are memory hungry. This blog entry discusses how work_mem might be improved: https://momjian.us/main/blogs/pgblog/2018.html#December_10_2018 -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.