Re: Large writable variables - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Large writable variables
Date
Msg-id 20181016201145.aa2dfeq54rhqzron@alap3.anarazel.de
Whole thread Raw
In response to Re: Large writable variables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Large writable variables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2018-10-16 10:16:33 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-10-16 01:59:00 -0400, Tom Lane wrote:
> >> Also, I noticed that the biggest part of those structs are arrays of
> >> FormatNode, which has been designed with complete lack of thought about
> >> size or padding issues.  We can very easily cut it in half on 64-bit
> >> machines.
> 
> > Heh, neat. I feel like we've paid very little attention to that in a
> > myriad of places :(
> 
> Most of the time, we probably *shouldn't* pay attention to it; logical
> field ordering is worth a good deal IMO.

Sure. But there's plenty structs which we allocate a bunch off, that are
frequently accessed, where a lot of space is wasted to padding.  I agree
that we don't need to contort many structs, but there's plenty where we
should.   Often enough it's possible to reorder without making things
make meaningfully less sense.

> But in a case like this,
> where there are large arrays of the things and it's not very painful
> to avoid padding waste, it's worth the trouble.

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...

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] heap_insert() and heap_update() optimization
Next
From: Tom Lane
Date:
Subject: Re: Large writable variables