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

From: "jacktby(at)gmail(dot)com" <jacktby(at)gmail(dot)com>
To: "Tomas Vondra" <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Re: Why the lp_len is 28 not 32?
Date: 2023-02-26 15:11:36
Message-ID: 2023022623113571772619@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


From: Tomas Vondra
Date: 2023-02-26 23:07
To: jacktby(at)gmail(dot)com; pgsql-hackers
Subject: Re: Why the lp_len is 28 not 32?
On 2/26/23 15:35, jacktby(at)gmail(dot)com wrote:
> use these sqls below:
> create table t(a int);
> insert into t values(1);
> select lp,lp_off,lp_len,t_data from heap_page_items(get_raw_page('t',0));
> lp | lp_off | lp_len | t_data
> ----+--------+--------+------------
> 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.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

yes, So it should be 32 bytes not 28bytes, but the sql result is 28 !!!!!! that's false!!!!
-------------------------------------------------
jacktby(at)gmail(dot)com;

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-02-26 15:23:03 Re: Give me more details of some bits in infomask!!
Previous Message Tomas Vondra 2023-02-26 15:07:21 Re: Why the lp_len is 28 not 32?