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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Re: Why the lp_len is 28 not 32?
Дата
Msg-id CAKFQuwZ9s36+OcYfdprPom90U5Y-DDtdiDmoUp6C=g4kSfUJjg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: Why the lp_len is 28 not 32?  ("jacktby@gmail.com" <jacktby@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "jacktby@gmail.com"
Дата:
Сообщение: Re: Re: Give me more details of some bits in infomask!!
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Re: Give me more details of some bits in infomask!!