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

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: [PoC] Improve dead tuple storage for lazy vacuum
Дата
Msg-id CANWCAZa29KNm2h6u8DejUa5N8Df0AiAtsZvKiycwg7f7muWUDg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PoC] Improve dead tuple storage for lazy vacuum  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: [PoC] Improve dead tuple storage for lazy vacuum  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Tue, Jan 30, 2024 at 7:56 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Mon, Jan 29, 2024 at 8:48 PM John Naylor <johncnaylorls@gmail.com> wrote:

> > 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;

It does make sense, but we can do it more simply:

Max(SLAB_DEFAULT_BLOCK_SIZE, pg_nextpower2_32(size * 32))



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Report planning memory in EXPLAIN ANALYZE
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: why there is not VACUUM FULL CONCURRENTLY?