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: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reducing Memory Consumption (aset and generation)
Date: 2022-06-07 00:14:35
Message-ID: CAEudQArZGRLu5r-WcHL5in6Y83oA2yvJRP6VTCOWyjEwEXL30A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em seg., 6 de jun. de 2022 às 20:37, David Rowley <dgrowleyml(at)gmail(dot)com>
escreveu:

> On Mon, 6 Jun 2022 at 07:28, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> > 4) 004-generation-reduces-memory-consumption-BUG.patch
> > Same to the (2), but with BUG.
> > It only takes a few tweaks to completely remove the field block.
>
> > This fails with make check.
> > I couldn't figure out why it doesn't work with 16 bits (struct
> GenerationChunk).
>
> Hi David, thanks for taking a look at this.

> I think you're misunderstanding how blocks and chunks work here. A
> block can have many chunks. You can't find the block that a chunk is
> on by subtracting Generation_BLOCKHDRSZ from the pointer given to
> GenerationFree(). That would only work if the chunk happened to be the
> first chunk on a block. If it's anything apart from that then you'll
> be making adjustments to the memory of some prior chunk on the block.
> I imagine this is the reason you can't get the tests to pass.
>
Ok, I am still learning about this.
Can you explain why subtracting Generation_BLOCKHDRSZ from the pointer,
works for sizeof(struct GenerationChunk) = 24 bits,
When all references for the block field have been removed.
This pass check-world.

>
> Can you also explain why you think moving code around randomly or
> adding unlikely() macros helps reduce the memory consumption overheads
> of generation contexts?

Of course, those changes do not reduce memory consumption.
But, IMO, I think those changes improve the access to memory regions,
because of the locality of the data.

About "unlikely macros", this helps the branchs prediction, when most of
the time,
malloc and related functions, will not fail.

> I imagine you think that's helping to further
> improve performance, but you've not offered any evidence of that
> separately from the other changes you've made. If you think those are
> useful changes then I recommend you run individual benchmarks and
> offer those as proof that those changes are worthwhile.
>
Ok, I can understand, are changes unrelated.

regards,
Ranier Vilela

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-06-07 00:25:24 Re: Collation version tracking for macOS
Previous Message Jim Nasby 2022-06-07 00:10:37 Re: Collation version tracking for macOS