Re: Add bump memory context type and use it for tuplesorts
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-02-20T23:48:13Z
Lists: pgsql-hackers
On Wed, 21 Feb 2024 at 00:02, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > > On Tue, 20 Feb 2024 at 11:02, David Rowley <dgrowleyml@gmail.com> wrote: > > On Fri, 26 Jan 2024 at 01:29, Matthias van de Meent > > <boekewurm+postgres@gmail.com> wrote: > > > >> + allocSize = MAXALIGN(sizeof(BumpContext)) + Bump_BLOCKHDRSZ + > > > >> + if (minContextSize != 0) > > > >> + allocSize = Max(allocSize, minContextSize); > > > >> + else > > > >> + allocSize = Max(allocSize, initBlockSize); > > > > > > Shouldn't this be the following, considering the meaning of "initBlockSize"? > > > > No, we want to make the blocksize exactly initBlockSize if we can. Not > > initBlockSize plus all the header stuff. We do it that way for all > > the other contexts and I agree that it's a good idea as it keeps the > > malloc request sizes powers of 2. > > One part of the reason of my comment was that initBlockSize was > ignored in favour of minContextSize if that was configured, regardless > of the value of initBlockSize. Is it deliberately ignored when > minContextSize is set? Ok, it's a good question. It's to allow finer-grained control over the initial block as it allows it to be a fixed given size without affecting the number that we double for the subsequent blocks. e.g BumpContextCreate(64*1024, 8*1024, 1024*1024); would make the first block 64K and the next block 16K, followed by 32K, 64K ... 1MB. Whereas, BumpContextCreate(0, 8*1024, 1024*1024) will start at 8K, 16K ... 1MB. It seems useful as you might have a good idea of how much memory the common case has and want to do that without having to allocate subsequent blocks, but if slightly more memory is required sometimes, you probably don't want the next malloc to be double the common size, especially if the common size is large. Apart from slab.c, this is how all the other contexts work. It seems best to keep this and not to go against the grain on this as there's more to consider if we opt to change the context types of existing contexts. David
Commits
-
Update mmgr's README to mention BumpContext
- 58cf2e120e8a 17.0 landed
-
Push dedicated BumpBlocks to the tail of the blocks list
- 6d2fd66b9908 17.0 landed
-
Improve test coverage in bump.c
- bea97cd02ebb 17.0 cited
-
Fix incorrect KeeperBlock macro in bump.c
- 705ec0565371 17.0 landed
-
Use bump memory context for tuplesorts
- 6ed83d5fa55c 17.0 landed
-
Introduce a bump memory allocator
- 29f6a959cfd8 17.0 landed
-
Enlarge bit-space for MemoryContextMethodID
- 0ba8b75e7ea6 17.0 landed