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 1lHUI7-00018i-3U for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Mar 2021 16:24:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lHUI6-0003vO-25 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Mar 2021 16:24:02 +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 1lHUI5-0003vH-SP for pgsql-hackers@lists.postgresql.org; Wed, 03 Mar 2021 16:24:01 +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 1lHUI3-0002f6-7i for pgsql-hackers@lists.postgresql.org; Wed, 03 Mar 2021 16:24: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 123GNsJV1183452; Wed, 3 Mar 2021 11:23:55 -0500 From: Tom Lane To: Georgios cc: Julien Rouhaud , PostgreSQL Hackers , "robertmhaas@gmail.com" Subject: Re: Shared memory size computation oversight? In-reply-to: References: <20210227080815.jryyhy6lrn6gahkm@nol> Comments: In-reply-to Georgios message dated "Wed, 03 Mar 2021 15:37:20 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1183450.1614788634.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 03 Mar 2021 11:23:54 -0500 Message-ID: <1183451.1614788634@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Georgios writes: > My limited understanding is also based in a comment in CreateSharedMemor= yAndSemaphores() > * Size of the Postgres shared-memory block is estimated via > * moderately-accurate estimates for the big hogs, plus 100K for= the > * stuff that's too small to bother with estimating. Right. That 100K slop factor is capable of hiding a multitude of sins. I have not looked at this patch, but I think the concern is basically that if we have space-estimation infrastructure that misestimates what it is supposed to estimate, then if that infrastructure is used to estimate the size of any of the "big hog" data structures, we might misestimate by enough that the slop factor wouldn't hide it. regards, tom lane