Re: PG 16 draft release notes ready - Mailing list pgsql-hackers

From David Rowley
Subject Re: PG 16 draft release notes ready
Date
Msg-id CAApHDvqmqxcX2n9NwvsfnsN0be6DjmyLSjz3Jk2DaZO5OLW+pw@mail.gmail.com
Whole thread Raw
In response to Re: PG 16 draft release notes ready  (Bruce Momjian <bruce@momjian.us>)
Responses Re: PG 16 draft release notes ready
List pgsql-hackers
On Wed, 31 May 2023 at 11:32, Bruce Momjian <bruce@momjian.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



pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: BF animal dikkop reported a failure in 035_standby_logical_decoding
Next
From: David Rowley
Date:
Subject: Re: [16Beta1][doc] pgstat: Track time of the last scan of a relation