Re: Simplify newNode()

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Simplify newNode()
Дата
Msg-id b5c2d75f-f871-4dae-a0e2-b35c4da0ca2c@eisentraut.org
обсуждение исходный текст
Ответ на Simplify newNode()  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Simplify newNode()  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On 14.12.23 01:48, Heikki Linnakangas wrote:
> The newNode() macro can be turned into a static inline function, which 
> makes it a lot simpler. See attached. This was not possible when the 
> macro was originally written, as we didn't require compiler to have 
> static inline support, but nowadays we do.
> 
> This was last discussed in 2008, see discussion at 
> https://www.postgresql.org/message-id/26133.1220037409%40sss.pgh.pa.us. 
> In those tests, Tom observed that gcc refused to inline the static 
> inline function. That was weird, the function is very small and doesn't 
> do anything special. Whatever the problem was, I think we can dismiss it 
> with modern compilers. It does get inlined on gcc 12 and clang 14 that I 
> have installed.

I notice that the existing comments point out that the size argument 
should be a compile-time constant, but that is no longer the case for 
ExtensibleNode().  Also, newNode() is the only caller of palloc0fast(), 
which also points out that the size argument should be a compile-time 
constant, and palloc0fast() is the only caller of MemSetTest().  I can 
see how an older compiler might have gotten too confused by all that. 
But if we think that compilers are now smart enough, maybe we can unwind 
this whole stack a bit more?  Maybe we don't need MemSetTest() and/or 
palloc0fast() and/or newNode() at all?




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

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: GUC names in messages