opensourcemirror
/
postgresql
mirror of git://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Update mmgr's README to mention BumpContext 

Oversight in 29f6a959c.

In passing, since we now have 4 memory context types to choose from,
provide a brief overview of the specialities of each memory context
type.

Reported-by: Amul Sul
Author: Amul Sul, David Rowley
Discussion: https://postgr.es/m/CAAJ_b94U2s9nHh--DEK=sPEZUQ+x7vQJ7529fF8UAH97QJ9NXg@mail.gmail.com
This commit is contained in:
David Rowley 2024-04-17 10:49:09 +12:00
parent 6d2fd66b99
commit 58cf2e120e
1 changed files with 22 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
src/backend/utils/mmgr/README
View File

@ -471,25 +471,32 @@ thrashing.
Alternative Memory Context Implementations
------------------------------------------
aset.c is our default general-purpose implementation, working fine
in most situations. We also have two implementations optimized for
special use cases, providing either better performance or lower memory
usage compared to aset.c (or both).
aset.c (AllocSetContext) is our default general-purpose allocator. Three other
allocator types also exist which are special-purpose:
* slab.c (SlabContext) is designed for allocations of fixed-length
chunks, and does not allow allocations of chunks with different size.
* slab.c (SlabContext) is designed for allocations of fixed-sized
chunks. The fixed chunk size must be specified when creating the context.
New chunks are allocated to the fullest block, keeping used chunks densely
packed together to avoid memory fragmentation. This also increases the
chances that pfree'ing a chunk will result in a block becoming empty of all
chunks and allow it to be free'd back to the operating system.
* generation.c (GenerationContext) is designed for cases when chunks
are allocated in groups with similar lifespan (generations), or
roughly in FIFO order.
* generation.c (GenerationContext) is best suited for cases when chunks are
allocated in groups with similar lifespan (generations), or roughly in FIFO
order. No attempt is made to reuse space left by pfree'd chunks. Blocks
are returned to the operating system when all chunks on them have been
pfree'd.
Both memory contexts aim to free memory back to the operating system
(unlike aset.c, which keeps the freed chunks in a freelist, and only
returns the memory when reset/deleted).
These memory contexts were initially developed for ReorderBuffer, but
may be useful elsewhere as long as the allocation patterns match.
* bump.c (BumpContext) is best suited for use cases that require densely
allocated chunks of memory that never need to be individually pfree'd or
repalloc'd. These operations are unsupported due to BumpContext chunks
having no chunk header. No chunk header means more densely packed chunks,
which is especially useful for workloads that perform lots of small
allocations. Blocks are only free'd back to the operating system when the
context is reset or deleted.
For further details, please read the header comment in the corresponding .c
file.
Memory Accounting
-----------------