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 1gCWQs-0004fB-J0 for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Oct 2018 20:59:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gCWQq-0005Lg-Gw for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Oct 2018 20:59:12 +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 1gCWQq-0005LK-2P for pgsql-hackers@lists.postgresql.org; Tue, 16 Oct 2018 20:59:12 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gCWQn-00024z-Mo for pgsql-hackers@postgresql.org; Tue, 16 Oct 2018 20:59:10 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id F1DDE22231; Tue, 16 Oct 2018 16:59:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 16 Oct 2018 16:59:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=eXHOQ5Q251lT5kWUTl+hIeIJOuK dLLSFZYCg4d+AmkI=; b=XExBrhENbgvwpYZaKtDEEZb7b72Jk/6HWaYP4EISFlF 8uwyQeX3AyKUFF7nH+SholgwHj9M99zgPyS8MSwBOXAvHVFLs5AxPDYEI5pMi/cM vsu+PfCMlid9Tib+aAm2qxR1ZJPLzyWQMhq9uVATXYD/c+aO6vuCK5EuCPgEzSex i58eUS5TgKeyPR2zSqWQHvcf/UB8wYi8JIW1lhFwx0Lzf3axmTzbttftx+6a0KCb awJyuYdyKWB97K3J9nZt4R5W89+Yu11sGnu+Pf8AFsx0hkUsfiIyUrLWVM1wWjj1 DwivwYGs/Z7bRGt+u7wNu2vdpoQ1bV0v6kSUSipcvTw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=eXHOQ5 Q251lT5kWUTl+hIeIJOuKdLLSFZYCg4d+AmkI=; b=hWUgil6Dl8q5fLgwJidyBU spsn8UqSyKoAzVVn7TH5clrf/eU2EbZTtMCXsDFTn5GrXl5h4b+Y/uyQPIviV3yY 90cbiRXR8AUm2s/xDUDOEeeZqWDw31dVMV/kykOpQLWSma0a6pCj3yPSr0c2ALy1 rdKqXhyyMwXJSAz+d+1tI6yoV0O3iyl7yLctXl24eJFLo6U249hckL/OBIqk6bBG 7rVh/7Jj4w2VCjTV7N698eKoTkZ4L9GB9PAhF/EaY6zSjUvfxSc0M48qhLwAnciG Utm3EI+60+Uv8HwARvzY9OyjgAF+4d4nJWAKSST85xkuw2tZ3PpVpz3fyKY8Ba9g == X-ME-Sender: X-ME-Proxy: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id B424C102A0; Tue, 16 Oct 2018 16:59:07 -0400 (EDT) Date: Tue, 16 Oct 2018 13:59:06 -0700 From: Andres Freund To: Tom Lane Cc: pgsql-hackers@postgresql.org, Thomas Munro Subject: Re: Large writable variables Message-ID: <20181016205906.hb2maf5l65kyo7ah@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> <26620.1539722172@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26620.1539722172@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2018-10-16 16:36:12 -0400, Tom Lane wrote: > 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. Possible, the new layout should work just as well there, luckily. > 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. I can't imagine that that outweight the cost of additional cache misses on any platform where performance matters. On x86 I assume indexing into an array with 24byte stride, will normally be just two leas (lea eax, [eax + eax * 2]; lea eax, [ebx + eax * 8]; where eax initially is the index, and ebx the array base). Indexing also plays less of a role than in the past, because previously we did a binary search, but now we normally look up the index via fmgr_builtin_oid_index. > What's the point of the extra const decoration on funcName? ISTM > the whole struct should be const, or not. The whole array is const. There's cases where that allows the compiler more freedom - but I guess it's really a bit redundant here. Greetings, Andres Freund