Re: [PoC] Improve dead tuple storage for lazy vacuum

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Date: 2024-01-30 00:55:35
Message-ID: CAD21AoBhM2wvwXB=DsqhMw41XP3UFMhWJZf62JD3Erk+wE72Fw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 29, 2024 at 8:48 PM John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
>
> On Mon, Jan 29, 2024 at 2:29 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> > > > +/*
> > > > + * Calculate the slab blocksize so that we can allocate at least 32 chunks
> > > > + * from the block.
> > > > + */
> > > > +#define RT_SLAB_BLOCK_SIZE(size) \
> > > > + Max((SLAB_DEFAULT_BLOCK_SIZE / (size)) * (size), (size) * 32)
> > > >
> > > > The first parameter seems to be trying to make the block size exact,
> > > > but that's not right, because of the chunk header, and maybe
> > > > alignment. If the default block size is big enough to waste only a
> > > > tiny amount of space, let's just use that as-is.
>
> > If we use SLAB_DEFAULT_BLOCK_SIZE (8kB) for each node class, we waste
> > [snip]
> > We might want to calculate a better slab block size for node256 at least.
>
> I meant the macro could probably be
>
> Max(SLAB_DEFAULT_BLOCK_SIZE, (size) * N)
>
> (Right now N=32). I also realize I didn't answer your question earlier
> about block sizes being powers of two. I was talking about PG in
> general -- I was thinking all block sizes were powers of two. If
> that's true, I'm not sure if it's because programmers find the macro
> calculations easy to reason about, or if there was an implementation
> reason for it (e.g. libc behavior). 32*2088 bytes is about 65kB, or
> just above a power of two, so if we did round that up it would be
> 128kB.

Thank you for your explanation. It might be better to follow other
codes. Does the calculation below make sense to you?

RT_SIZE_CLASS_ELEM size_class = RT_SIZE_CLASS_INFO[i];
Size inner_blocksize = SLAB_DEFAULT_BLOCK_SIZE;
while (inner_blocksize < 32 * size_class.allocsize)
inner_blocksize <<= 1;

As for the lock mode in dsa.c, I've posted a question[1].

Regards,

[1] https://www.postgresql.org/message-id/CAD21AoALgrU2sGWzgq%2B6G9X0ynqyVOjMR5_k4HgsGRWae1j%3DwQ%40mail.gmail.com

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2024-01-30 01:15:50 Re: When extended query protocol ends?
Previous Message Masahiko Sawada 2024-01-30 00:53:19 Question on LWLockMode in dsa.c