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