Re: Change xl_hash_vacuum_one_page.ntuples from int to uint16 - Mailing list pgsql-hackers
From | Drouvot, Bertrand |
---|---|
Subject | Re: Change xl_hash_vacuum_one_page.ntuples from int to uint16 |
Date | |
Msg-id | c38dd169-b704-8394-4274-0bc9b33a7b9e@gmail.com Whole thread Raw |
In response to | Re: Change xl_hash_vacuum_one_page.ntuples from int to uint16 (Amit Kapila <amit.kapila16@gmail.com>) |
Responses |
Re: Change xl_hash_vacuum_one_page.ntuples from int to uint16
Re: Change xl_hash_vacuum_one_page.ntuples from int to uint16 |
List | pgsql-hackers |
Hi, On 2/16/23 12:00 PM, Amit Kapila wrote: > On Wed, Feb 15, 2023 at 3:35 AM Nathan Bossart <nathandbossart@gmail.com> wrote: >> >> On Sat, Jan 21, 2023 at 06:42:08AM +0100, Drouvot, Bertrand wrote: >>> On 1/20/23 9:01 PM, Nathan Bossart wrote: >>>> Should we also change the related >>>> variables (e.g., ndeletable in _hash_vacuum_one_page()) to uint16? >>> >>> Yeah, I thought about it too. What I saw is that there is other places that would be good candidates for the same >>> kind of changes (see the int ntodelete argument in gistXLogDelete() being assigned to gistxlogDelete.ntodelete (uint16)for example). >>> >>> So, what do you think about: >>> >>> 1) keep this patch as it is (to "only" address the struct field and avoid possible future "useless" padding size increase) >>> and >>> 2) create a new patch (once this one is committed) to align the types for variables/arguments with the structs (relatedto XLOG records) fields when they are not? >> >> Okay. I've marked this one as ready-for-committer, then. >> > > LGTM. Thanks for looking at it! > I think the padding space we are trying to save here can be used > for the patch [1], right? Yes exactly, without the current patch and adding isCatalogRel (from the patch [1] you mentioned) we would get: (gdb) ptype /o struct xl_hash_vacuum_one_page /* offset | size */ type = struct xl_hash_vacuum_one_page { /* 0 | 4 */ TransactionId snapshotConflictHorizon; /* 4 | 4 */ int ntuples; /* 8 | 1 */ _Bool isCatalogRel; /* XXX 3-byte padding */ /* total size (bytes): 12 */ } While with the proposed patch: (gdb) ptype /o struct xl_hash_vacuum_one_page /* offset | size */ type = struct xl_hash_vacuum_one_page { /* 0 | 4 */ TransactionId snapshotConflictHorizon; /* 4 | 2 */ uint16 ntuples; /* 6 | 1 */ _Bool isCatalogRel; /* XXX 1-byte padding */ /* total size (bytes): 8 */ } > BTW, feel free to create the second patch > (to align the types for variables/arguments) as that would be really > helpful after we commit this one. > Yes, will do. > I think this would require XLOG_PAGE_MAGIC as it changes the WAL record. > Oh, I Was not aware about it, thanks! Will do in V2 (and in the logical decoding on standby patch as it adds the new field mentioned above). > BTW, how about a commit message like: > Change xl_hash_vacuum_one_page.ntuples from int to uint16. > > This will create two bytes of padding space in xl_hash_vacuum_one_page > which can be used for future patches. This makes the datatype of > xl_hash_vacuum_one_page.ntuples same as gistxlogDelete.ntodelete which > is advisable as both are used for the same purpose. > LGTM, will add it to V2! Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
pgsql-hackers by date: