Re: Reducing Memory Consumption (aset and generation)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reducing Memory Consumption (aset and generation)
Date: 2022-07-13 00:23:45
Message-ID: CAEudQAq7ToYUx+UebiuNiHad76XPPf36_0SL40dEg44BJqK1nA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em ter., 12 de jul. de 2022 às 02:35, David Rowley <dgrowleyml(at)gmail(dot)com>
escreveu:

> On Mon, 11 Jul 2022 at 20:48, Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2022-07-13 00:36:15 Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns
Previous Message Michael Paquier 2022-07-13 00:03:31 Re: pg15b2: large objects lost on upgrade