From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Is it really such a good thing for newNode() to be a macro? |
Date: | 2008-08-27 14:32:13 |
Message-ID: | 48B5656D.6010909@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> Note that the MemSetLoop macro used in palloc0fast is supposed to be
>> evaluated at compile time,
>
> Oooh, good point, I had forgotten about that little detail. Yeah,
> we'll lose that optimization if we move the code out-of-line.
Well, we could still have the MemSetTest outside the function, and
evaluated at compile-time, if we provided an aligned and unaligned
version of newNode:
#define newNode(size, tag) \
( \
AssertMacro((size) >= sizeof(Node)), /* need the tag, at least */ \
( MemSetTest(0, sz) ? \
newNodeAligned(CurrentMemoryContext, sz, tag) : \
newNodeNotAligned(CurrentMemoryContext, sz, tag))
And if you're worried about the function call overhead,
newNode(Not)Aligned could have the contents of MemoryContextAllocZero
inlined into it. Not sure how much optimization is worthwhile here..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-08-27 14:41:05 | Re: Is it really such a good thing for newNode() to be a macro? |
Previous Message | Benedek László | 2008-08-27 14:17:43 | Re: pg_dump roles support |