Re: Changing types of block and chunk sizes in memory contexts

From: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Changing types of block and chunk sizes in memory contexts
Date: 2023-07-10 14:41:11
Message-ID: CAGPVpCS_+nQQgRzsqcUq_ESaj4MtVZ53G=NR5zYu-g9B5oa4_w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Thanks for your comments.

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 28 Haz 2023 Çar, 13:59 tarihinde şunu yazdı:
>
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > Perhaps it's ok to leave the context creation functions with Size
> > typed parameters and then just Assert the passed-in sizes are not
> > larger than 1GB within the context creation function.
>
> Yes, I'm strongly opposed to not using Size/size_t in the mmgr APIs.
> If we go that road, we're going to have a problem when someone
> inevitably wants to pass a larger-than-GB value for some context
> type.

I reverted changes in the context creation functions and only changed
the types in structs.
I believe there are already lines to assert whether the sizes are less
than 1GB, so we should be safe there.

Andres Freund <andres(at)anarazel(dot)de>, 29 Haz 2023 Per, 02:34 tarihinde şunu yazdı:
> There are a few other fields that we can get rid of.
>
> - Afaics AllocSet->keeper is unnecessary these days, as it is always allocated
> together with the context itself. Saves 8 bytes.

This seemed like a safe change and removed the keeper field in
AllocSet and Generation contexts. It saves an additional 8 bytes.

Best,
--
Melih Mutlu
Microsoft

Attachment Content-Type Size
v2-0001-Change-memory-context-fields-to-uint32.patch application/octet-stream 12.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2023-07-10 14:43:23 Re: Reducing connection overhead in pg_upgrade compat check phase
Previous Message Melih Mutlu 2023-07-10 14:31:24 Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication