Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gCW4o-00030I-Nw for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Oct 2018 20:36:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gCW4m-0006od-EH for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Oct 2018 20:36:24 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gCW4m-0006oW-0f for pgsql-hackers@lists.postgresql.org; Tue, 16 Oct 2018 20:36:24 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gCW4f-0001bV-AG for pgsql-hackers@postgresql.org; Tue, 16 Oct 2018 20:36:22 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w9GKaC4t026621; Tue, 16 Oct 2018 16:36:12 -0400 From: Tom Lane To: Andres Freund cc: pgsql-hackers@postgresql.org, Thomas Munro Subject: Re: Large writable variables In-reply-to: <20181016201145.aa2dfeq54rhqzron@alap3.anarazel.de> References: <20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de> <31562.1539658872@sss.pgh.pa.us> <6813.1539669540@sss.pgh.pa.us> <20181016063317.xjfd2dnlhy6tg5gx@alap3.anarazel.de> <30245.1539699393@sss.pgh.pa.us> <20181016201145.aa2dfeq54rhqzron@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Tue, 16 Oct 2018 13:11:45 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26619.1539722172.1@sss.pgh.pa.us> Date: Tue, 16 Oct 2018 16:36:12 -0400 Message-ID: <26620.1539722172@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > Attached is a patch that shrinks fmgr_builtins by 25%. That seems > worthwhile, it's pretty frequently accessed, making it more dense is > helpful. Unless somebody protests soon, I'm going to apply that... Hah. I'm pretty sure that struct *was* set up with an eye to padding ... on 32-bit machines. This does make it shorter on 64-bit, but also makes the size not a power of 2, which might add a few cycles to array indexing calculations. Might be worth checking whether that's going to be an issue anywhere. What's the point of the extra const decoration on funcName? ISTM the whole struct should be const, or not. regards, tom lane