Re: PG 16 draft release notes ready

On Wed, 31 May 2023 at 11:32, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Thu, May 25, 2023 at 05:57:25PM +1200, David Rowley wrote:
> > On 64-bit builds, it was 16 bytes for AllocSet contexts, 24 bytes for
> > generation contexts and 16 bytes for slab contexts.
>
> Okay, item added to Source Code:

I don't think this should go under "E.1.3.11. Source Code". The patch
was entirely aimed to increase performance, not just of allocations
themselves, but of any operations which uses palloc'd memory. This is
due to the patch increasing the density of memory allocation on blocks
malloc'd by our memory context code so that fewer CPU cache lines need
to be touched in the entire backend process for *all* memory that's
allocated with palloc. The performance increase here can be fairly
significant for small-sized palloc requests when CPU cache pressure is
high. Since CPU caches aren't that big, it does not take much of a
query to put the cache pressure up. Hashing or sorting a few million
rows is going to do that.

The patch here was born out of the regression report I made in [1],
which I mention in [2] about the prototype patch Andres wrote to fix
the performance regression.

I think "E.1.3.1.2. General Performance" might be a better location.
Having it under "Source Code" makes it sound like it was some
refactoring work. That's certainly not the case.

A bit more detail:

Here's a small histogram of the number of allocations in various size
buckets from running make check with some debug output in
AllocSetAlloc and GenerationAlloc to record the size of the
allocation:

bucket | number_of_allocations | percent_of_total_allocations
----------------+-----------------------+---------
up to 16 bytes | 8,881,106 | 31.39
up to 32 bytes | 4,579,608 | 16.18
up to 64 bytes | 6,574,107 | 23.23
above 64 bytes | 8,260,714 | 29.19

So quite a large portion of our allocations (at least in our test
suite) are small. Halving the 16-byte chunk header down 8 bytes on a
16-byte allocation means a 25% memory saving.

David

[1] https://www.postgresql.org/message-id/CAApHDvqXpLzav6dUeR5vO_RBh_feHrHMLhigVQXw9jHCyKP9PA%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAApHDvowHNSVLhMc0cnovg8PfnYQZxit-gP_bn3xkT4rZX3G0w%40mail.gmail.com