pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Subject: Re: Large writable variables
Date: Tue, 16 Oct 2018 13:59:06 -0700
Message-ID: <20181016205906.hb2maf5l65kyo7ah@alap3.anarazel.de> (raw)
In-Reply-To: <26620.1539722172@sss.pgh.pa.us>
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>

On 2018-10-16 16:36:12 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> 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




view thread (51+ messages)  latest in thread

Message-ID: <20181016205906.hb2maf5l65kyo7ah@alap3.anarazel.de>
Permalink:  ../20181016205906.hb2maf5l65kyo7ah@alap3.anarazel.de/
Also on:    postgresql.org/message-id/20181016205906.hb2maf5l65kyo7ah@alap3.anarazel.de

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: andres@anarazel.de, tgl@sss.pgh.pa.us, thomas.munro@enterprisedb.com
  Subject: Re: Large writable variables
  In-Reply-To: <20181016205906.hb2maf5l65kyo7ah@alap3.anarazel.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox