Re: More speedups for tuple deformation

Hi David and Tender,

On Mon, Mar 16, 2026 at 5:17 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Mon, 16 Mar 2026 at 20:01, Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> > SELECT * FROM t2, t4 RIGHT OUTER JOIN t0 ON t4.c0 WHERE t4.c1 ORDER BY
>
> > server closed the connection unexpectedly
>
> Thanks. Looks like I didn't get the startAttr logic correct in
> nocachegetattr(). Starting by using the attcacheoff of the first NULL
> attribute isn't valid. It should be the attribute prior to that one.
>
> I'm just verifying some code locally now.
>
> David
>
>

The following case is more simpler:

drop table if exists ty;
create table ty(c0 int not null, c1 double precision, c2 int4range);
insert into ty values (1, 1.0, '[1469060470,1895771979)');
insert into ty values(2, null, '[-1973503943,635641598)');
select * from ty order by c2;

In this case, firstNonCachedOffsetAttr is 2 and firstNullAttr is 1.
If we start from 1, the cached offset becomes 8 due to double's
alignby, and deforming int4range from offset 8 will lead to corrupted data.
Therefore, as David said, we should start from the attribute prior
to that one. PFA is a trivial fix, I think we should add the test but
I haven't found a proper regress test file for it.

--
Regards
Junwang Zhao