1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update mmgr's README to mention BumpContext

Browse Source 
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 Alternative Memory Context Implementations
------------------------------------------ ------------------------------------------
aset.c is our default general-purpose implementation, working fine aset.c (AllocSetContext) is our default general-purpose allocator. Three other
in most situations. We also have two implementations optimized for allocator types also exist which are special-purpose:
special use cases, providing either better performance or lower memory
usage compared to aset.c (or both).
* slab.c (SlabContext) is designed for allocations of fixed-length * slab.c (SlabContext) is designed for allocations of fixed-sized
chunks, and does not allow allocations of chunks with different size. 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 * generation.c (GenerationContext) is best suited for cases when chunks are
are allocated in groups with similar lifespan (generations), or allocated in groups with similar lifespan (generations), or roughly in FIFO
roughly in FIFO order. 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 * bump.c (BumpContext) is best suited for use cases that require densely
(unlike aset.c, which keeps the freed chunks in a freelist, and only allocated chunks of memory that never need to be individually pfree'd or
returns the memory when reset/deleted). repalloc'd. These operations are unsupported due to BumpContext chunks
having no chunk header. No chunk header means more densely packed chunks,
These memory contexts were initially developed for ReorderBuffer, but which is especially useful for workloads that perform lots of small
may be useful elsewhere as long as the allocation patterns match. 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 Memory Accounting
----------------- -----------------