From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CLUSTER can change t_len |
Date: | 2010-11-09 13:57:55 |
Message-ID: | AANLkTin6DiCOeyAwPKk73+cs9Zm-XG4KxhxdW3hx2zN=@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 9, 2010 at 10:20 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>
>> We have a comment /* be conservative */ in the function, but I'm not sure
>> we actually need the MAXALIGN. However, there would be almost no benefits
>> to keep t_len in small value because we often treat memory in MAXALIGN
>> unit.
>
> Hmm, the conservatism at that point affects the free space calculations. I'm
> not sure if it makes any difference in practice, but I'm also not sure it
> doesn't. pd_upper is always MAXALIGNed, but pd_lower is not.
>
> This would be more in line with what the main heap_insert code does:
>
Doesn't this cause assertion failures in heap_fill_tuple when the data
size isn't what's expected? I guess we never actually use the t_len
for later tuple reconstructions, we just recompute the needed size?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira de Oliveira | 2010-11-09 14:06:55 | pg_ctl init doc bug |
Previous Message | Greg Stark | 2010-11-09 13:45:01 | Re: Protecting against unexpected zero-pages: proposal |