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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
