Re: Add bump memory context type and use it for tuplesorts - Mailing list pgsql-hackers

From David Rowley
Subject Re: Add bump memory context type and use it for tuplesorts
Date
Msg-id CAApHDvqjetv2pBSBrbA-_Z2DM8oA3Ay0y6GxDYPie2s+Ta2ALQ@mail.gmail.com
Whole thread Raw
In response to Re: Add bump memory context type and use it for tuplesorts  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add bump memory context type and use it for tuplesorts
List 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 by date:

Previous
From: Jelte Fennema-Nio
Date:
Subject: Re: Possibility to disable `ALTER SYSTEM`
Next
From: Bruce Momjian
Date:
Subject: Re: Possibility to disable `ALTER SYSTEM`