Re: Add bump memory context type and use it for tuplesorts
От | David Rowley |
---|---|
Тема | Re: Add bump memory context type and use it for tuplesorts |
Дата | |
Msg-id | CAApHDvqjetv2pBSBrbA-_Z2DM8oA3Ay0y6GxDYPie2s+Ta2ALQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add bump memory context type and use it for tuplesorts (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add bump memory context type and use it for tuplesorts
|
Список | pgsql-hackers |
On Tue, 26 Mar 2024 at 03:53, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I agree with this completely. However, the current design for chunk > headers is mighty restrictive about how many kinds of contexts we can > have. We need to open that back up. Andres mentioned how we could do this in [1]. One possible issue with that is that slab.c has no external chunks so would restrict slab to 512MB chunks. I doubt that's ever going to realistically be an issue. That's just not a good use case for slab, so I'd be ok with that. > Could we move the knowledge of exactly which context type it is out > of the per-chunk header and keep it in the block header? This'd > require that every context type have a standardized way of finding > the block header from a chunk. We could repurpose the existing > MemoryContextMethodID bits to allow having a small number of different > ways, perhaps. I wasn't 100% clear on your opinion about using 010 vs expanding the bit-space. Based on the following it sounded like you were not outright rejecting the idea of consuming the 010 pattern. On Sat, 17 Feb 2024 at 12:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If we do kick this can down the road, then I concur with eating 010 > next, as it seems the least likely to occur in glibc-malloced > chunks. David [1] https://postgr.es/m/20240217200845.ywlwenjrlbyoc73v@awork3.anarazel.de
В списке pgsql-hackers по дате отправления: