From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, John Gorman <johngorman2(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH: two slab-like memory allocators |
Date: | 2017-02-28 03:57:24 |
Message-ID: | 1240.1488254244@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Independently of this, we really should redefine StandardChunkHeader to
> be only the MemoryContext. There's no need to have size/requested_size
> part of StandardChunkHeader, given there's
> MemoryContextMethods->get_chunk_space().
Yeah, perhaps. The trick would be to get things laid out so that the
MemoryContext pointer is always immediately adjacent to the chunk data
(no padding between).
One could imagine redefining aset.c's chunk header along the lines of
typedef struct AllocSetChunkHeader
{
Size size; /* size of data space allocated in chunk */
#ifdef MEMORY_CONTEXT_CHECKING
Size requested_size; /* original request size */
#if 32-bit-but-maxalign-is-8
Size padding; /* needed to avoid padding below */
#endif
#endif
MemoryContext context; /* owning context */
/* there must not be any padding to reach a MAXALIGN boundary here! */
} AllocSetChunkHeader;
where we'd possibly need some help from configure to implement that inner
#if condition, but it seems doable enough.
If the slab allocator would be happier with just a MemoryContext pointer
as chunk header, I think we should push in this direction rather than
invent some short-term hack.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-02-28 04:08:34 | Re: Partitioned tables and relfilenode |
Previous Message | Petr Jelinek | 2017-02-28 03:50:40 | Re: logical replication access control patches |