On 2014-11-17 19:42:25 +0100, Tomas Vondra wrote:
> On 17.11.2014 18:04, Andres Freund wrote:
> > Hi,
> >
> > On 2014-11-16 23:31:51 -0800, Jeff Davis wrote:
> >> *** a/src/include/nodes/memnodes.h
> >> --- b/src/include/nodes/memnodes.h
> >> ***************
> >> *** 60,65 **** typedef struct MemoryContextData
> >> --- 60,66 ----
> >> MemoryContext nextchild; /* next child of same parent */
> >> char *name; /* context name (just for debugging) */
> >> bool isReset; /* T = no space alloced since last reset */
> >> + uint64 mem_allocated; /* track memory allocated for this context */
> >> #ifdef USE_ASSERT_CHECKING
> >> bool allowInCritSection; /* allow palloc in critical section */
> >> #endif
> >
> > That's quite possibly one culprit for the slowdown. Right now one
> > AllocSetContext struct fits precisely into three cachelines. After
> > your change it doesn't anymore.
>
> I'm no PPC64 expert, but I thought the cache lines are 128 B on that
> platform, since at least Power6?
Hm, might be true.
> Also, if I'm counting right, the MemoryContextData structure is 56B
> without the 'mem_allocated' field (and without the allowInCritSection),
> and 64B with it (at that particular place). sizeof() seems to confirm
> that. (But I'm on x86, so maybe the alignment on PPC64 is different?).
The MemoryContextData struct is embedded into AllocSetContext.
> > Consider not counting memory in bytes but blocks and adding it
> > directly after the NodeTag. That'd leave the size the same as right
> > now.
>
> I suppose you mean "kbytes", because the block size is not fixed.
Some coarser size than bytes. Don't really care about the granularity.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services