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:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Some revises in adding sorting path
Next
From: Bharath Rupireddy
Date:
Subject: Re: pg_walinspect memory leaks