On Sun, Feb 26, 2023 at 8:11 AM jack...@gmail.com <jack...@gmail.com> wrote:
> > *From:* Tomas Vondra <tomas.von...@enterprisedb.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.
