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 по дате отправления: