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;
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? |