Re: Large writable variables

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Large writable variables
Дата
Msg-id 20181016201145.aa2dfeq54rhqzron@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Large writable variables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Large writable variables
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] heap_insert() and heap_update() optimization
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Large writable variables