Re: Re: Why the lp_len is 28 not 32?

On Sun, Feb 26, 2023 at 8:11 AM jacktby(at)gmail(dot)com <jacktby(at)gmail(dot)com> wrote:

>
> *From:* Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
>
> > ----+--------+--------+------------
> > 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.