Re: Reducing Memory Consumption (aset and generation)

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Reducing Memory Consumption (aset and generation)
Дата
Msg-id CAEudQAq7ToYUx+UebiuNiHad76XPPf36_0SL40dEg44BJqK1nA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reducing Memory Consumption (aset and generation)  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
Em ter., 12 de jul. de 2022 às 02:35, David Rowley <dgrowleyml@gmail.com> escreveu:
On Mon, 11 Jul 2022 at 20:48, Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> > 2) v1-002-generation-reduces-memory-consumption.patch
> > Reduces memory used by struct GenerationBlock, by minus 8 bits,
>
> That seems fairly straight-forward -- 8 bytes saved on each page isn't
> a lot, but it's something.

I think 002 is likely the only patch here that has some merit.
However, it's hard to imagine any measurable performance gains from
it.  I think the smallest generation block we have today is 8192
bytes. Saving 8 bytes in that equates to a saving of 0.1% of memory.
For an 8MB page, it's 1024 times less than that.

I imagine Ranier has been working on this due the performance
regression mentioned in [1].  I think it'll be much more worthwhile to
aim to reduce the memory chunk overheads rather than the block
overheads, as Ranier is doing here. I posted a patch in [2] which does
that.  To make that work, I need to have the owning context in the
block. The 001 and 003 patch seems to remove those here.
I saw the numbers at [2], 17% is very impressive.
How you need the context in the block, 001 and 003,
they are more of a hindrance than a help.

So, feel free to incorporate 002 into your patch if you wish.
The best thing to do here is to close and withdraw from commitfest.

regards,
Ranier Vilela

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg15b2: large objects lost on upgrade
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns