| From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
| Date: | 2014-11-17 18:42:25 |
| Message-ID: | 546A4191.7080300@fuzzy.cz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-11-17 18:46:21 | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |
| Previous Message | Robert Haas | 2014-11-17 18:24:46 | Re: New Event Trigger: table_rewrite |