Horton

Re: Add bump memory context type and use it for tuplesorts

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: David Rowley <dgrowleyml@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-25T14:53:12Z
Lists: pgsql-hackers 
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> IMHO the idea of having a general purpose memory context and then also
> specialized memory contexts for particular allocation patterns is great,
> and we should embrace it. Adding more and more special cases into
> AllocSet seems to go directly against that idea, makes the code more
> complex, and I don't quite see how is that better or easier to use than
> having a separate BumpContext ...

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.

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.

			regards, tom lane

Commits

  1. Update mmgr's README to mention BumpContext

  2. Push dedicated BumpBlocks to the tail of the blocks list

  3. Improve test coverage in bump.c

  4. Fix incorrect KeeperBlock macro in bump.c

  5. Use bump memory context for tuplesorts

  6. Introduce a bump memory allocator

  7. Enlarge bit-space for MemoryContextMethodID