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