Re: Re: Why the lp_len is 28 not 32? - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Re: Why the lp_len is 28 not 32?
Date
Msg-id CAKFQuwZ9s36+OcYfdprPom90U5Y-DDtdiDmoUp6C=g4kSfUJjg@mail.gmail.com
Whole thread Raw
In response to Re: Re: Why the lp_len is 28 not 32?  ("jacktby@gmail.com" <jacktby@gmail.com>)
List pgsql-hackers
On Sun, Feb 26, 2023 at 8:11 AM jacktby@gmail.com <jacktby@gmail.com> wrote:
 
> ----+--------+--------+------------
>   1 |   8160 |     28 | \x01000000
> --------------------------------------------------------------------------------
 
Pretty sure this is because we align the data to MAXALIGN, and on x86_64
that's 8 bytes. 28 is not a multiple of 8 while 32 is.
 
>> yes, So it should be 32 bytes not 28bytes, but the sql result is 28 !!!!!! that's false!!!!


No, that is a definition not matching your expectation.  Are you trying to demonstrate a bug here or just observing that your intuition of this didn't work here?

The content doesn't include alignment padding.  The claim isn't that the size is "the number of bytes consumed in some place within the page" but rather the size is "the number of bytes needed to get the content required to be passed into the input function for the datatype".  Nicely, it is trivial to then align the value to figure out the consumed width.  If you just have the aligned size you would never know how many bytes you need for the data value.

David J.

pgsql-hackers by date:

Previous
From: "jacktby@gmail.com"
Date:
Subject: Re: Re: Give me more details of some bits in infomask!!
Next
From: "David G. Johnston"
Date:
Subject: Re: Re: Give me more details of some bits in infomask!!