Re: Reducing the chunk header sizes on all memory context types

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Reducing the chunk header sizes on all memory context types
Date: 2022-09-07 04:13:37
Message-ID: CAApHDvrbg1QmHLB3NB_3D22m8Jsq26x98ZjO05pGac+RLn705w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 6 Sept 2022 at 01:41, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Fri, 2 Sept 2022 at 20:11, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> >
> > On Thu, 1 Sept 2022 at 12:46, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >
> > > David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > > > Maybe we should just consider always making room for a sentinel for
> > > > chunks that are on dedicated blocks. At most that's an extra 8 bytes
> > > > in some allocation that's either over 1024 or 8192 (depending on
> > > > maxBlockSize).
> > >
> > > Agreed, if we're not doing that already then we should.
> >
> > Here's a patch to that effect.
>
> If there are no objections, then I plan to push that patch soon.

I've now pushed the patch which adds the sentinel space in more cases.

The final analysis I did on the stats gathered during make
installcheck show that we'll now allocate about 19MBs more over the
entire installcheck run out of about 26GBs total allocations.

That analysis looks something like:

Before:

SELECT CASE
WHEN pow2_size > 0
AND pow2_size = size THEN 'No'
WHEN pow2_size = 0
AND size = maxalign_size THEN 'No'
ELSE 'Yes'
END AS has_sentinel,
Count(*) AS n_allocations,
Sum(CASE
WHEN pow2_size > 0 THEN pow2_size
ELSE maxalign_size
END) / 1024 / 1024 mega_bytes_alloc
FROM memstats
GROUP BY 1;
has_sentinel | n_allocations | mega_bytes_alloc
--------------+---------------+------------------
No | 26445855 | 21556
Yes | 37602052 | 5044

After:

SELECT CASE
WHEN pow2_size > 0
AND pow2_size = size THEN 'No'
WHEN pow2_size = 0
AND size = maxalign_size THEN 'Yes' -- this part changed
ELSE 'Yes'
END AS has_sentinel,
Count(*) AS n_allocations,
Sum(CASE
WHEN pow2_size > 0 THEN pow2_size
WHEN size = maxalign_size THEN maxalign_size + 8
ELSE maxalign_size
END) / 1024 / 1024 mega_bytes_alloc
FROM memstats
GROUP BY 1;
has_sentinel | n_allocations | mega_bytes_alloc
--------------+---------------+------------------
No | 23980527 | 2177
Yes | 40067380 | 24442

That amounts to previously having about 58.7% of allocations having a
sentinel up to 62.6% currently, during the installcheck run.

It seems a pretty large portion of allocation request sizes are
power-of-2 sized and use AllocSet.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2022-09-07 04:22:53 Re: Handle infinite recursion in logical replication setup
Previous Message Amit Kapila 2022-09-07 03:46:54 Re: pgsql: Add ALTER SUBSCRIPTION ... SKIP.