Re: Simplify newNode() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Simplify newNode()
Date
Msg-id b5c2d75f-f871-4dae-a0e2-b35c4da0ca2c@eisentraut.org
Whole thread Raw
In response to Simplify newNode()  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Simplify newNode()
List 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 by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Next
From: Peter Eisentraut
Date:
Subject: Re: GUC names in messages