On Wed, 10 Aug 2022 at 09:23, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Andres Freund <and...@anarazel.de> writes: > > On 2022-08-09 15:21:57 -0400, Tom Lane wrote: > >> Do we really need it to be that tight? I know we only have 3 methods > >> today, > >> but 8 doesn't seem that far away. If there were six bits reserved for > >> this I'd be happier. > > > We only have so many bits available, so that'd have to come from some other > > resource. The current division is: > > > + * 1. 3-bits to indicate the MemoryContextMethodID > > + * 2. 1-bit to indicate if the chunk is externally managed (see > > below) > > + * 3. 30-bits for the amount of memory which was reserved for the > > chunk > > + * 4. 30-bits for the number of bytes that must be subtracted from > > the chunk > > + * to obtain the address of the block that the chunk is stored > > on. > > > I suspect we could reduce 3) here a bit, which I think would end up with > > slab > > context's max chunkSize shrinking further. Which should still be fine. > > Hmm, I suppose you mean we could reduce 4) if we needed to. Yeah, that > seems like a reasonable place to buy more bits later if we run out of > MemoryContextMethodIDs. Should be fine then.
I think he means 3). If 4) was reduced then that would further reduce the maxBlockSize we could pass when creating a context. At least for aset.c and generation.c, we don't really need 3) to be 30-bits wide as the set->allocChunkLimit is almost certainly much smaller than that. Allocations bigger than allocChunkLimit use a dedicated block with an external chunk. External chunks don't use 3) or 4). David
