Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
От | Tomas Vondra |
---|---|
Тема | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
Дата | |
Msg-id | 546A4191.7080300@fuzzy.cz обсуждение исходный текст |
Ответ на | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: 9.5: Better memory accounting, towards memory-bounded
HashAgg
|
Список | pgsql-hackers |
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? 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?). > 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. regards Tomas
В списке pgsql-hackers по дате отправления: