MIME-Version: 1.0
References: 
 <CAApHDvpbntG7V3_EsZ+w-V=jU-y8rFmv9RB1EDJm4sxKno-4UA@mail.gmail.com>
 <e7sto7tk5dk5hfyvoocaddnxcngemcmfvbuh23l32w5cssaizy@znuphjqug7qe>
 <CAApHDvpuEbhvH1ViCZRz5vks+_bGbEnPoEdZYAZXK76_isb_+Q@mail.gmail.com>
 <v6z545yozjtywghn5glujemu72z4i4ynadsc2xks4ejotdg7yl@4rry7ixwr4us>
 <CANWCAZabO1oj+khF+YNVpmkTQwRRyNJesbsBhRFL5emZJh3tow@mail.gmail.com>
 <lzgoxzbh2gel5w362revuwaecrsbjr44kjdzrewuejugcodkeq@ixymojwnylsy>
 <CAApHDvodSVBj3ypOYbYUCJX+NWL=VZs63RNBQ_FxB_F+6QXF-A@mail.gmail.com>
 <rbxc2qqhsvzxpukgd36caoa4ydgn5r22fxktxanrkn6nobg7j6@27b4vogohgu2>
 <CAApHDvpWQn8sXDYpSNNpieJW-UTG4Nf4TVjT8ew64L073hz-Fw@mail.gmail.com>
 <mq6ddpgctt42srolsvo5kph2s6shfg62meb7i5fbg6n3s73zju@2n7gviiyga3h>
 <uhqul2ryci4tyg5ylddjrmf4kybzwb7m5z7rmurhhjp37vrn5f@zgxil7egr62n>
 <CAApHDvq21qQigiM6z2YgadFusQC_pfEYP8D=oQCrwJ_kKzcqDg@mail.gmail.com>
 <CAApHDvpdB1t7LCgH8=KOKC6VBb2rsEbaas0FiXo5awsRgCsDxQ@mail.gmail.com>
 <CAEG8a3KeKcZxJsH9nL+D1JzC4Ekx51ps7-1ZGWkwdXbPS5jTXw@mail.gmail.com>
 <CAApHDvqp_DGNkz3Rr29hPuSYdai5c_32mWSv2inrW2ufsE+qZQ@mail.gmail.com>
 <CAHewXNnb-s_=VdVUZ9h7dPA0u3hxV8x2aU3obZytnqQZ_MiROA@mail.gmail.com>
 <CAApHDvrFmW+2GhdDKuWRaJmp8MfghmBiEGaeqjOD_Y2RWUFSow@mail.gmail.com>
In-Reply-To: 
 <CAApHDvrFmW+2GhdDKuWRaJmp8MfghmBiEGaeqjOD_Y2RWUFSow@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Tue, 17 Mar 2026 10:15:45 +1300
Message-ID: 
 <CAApHDvoy9AJ4D2+pJE0ZRhPPCHh-Mm-sZAfookKtf_3V+GeP0g@mail.gmail.com>
Subject: Re: More speedups for tuple deformation
To: Tender Wang <tndrwang@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, John Naylor <johncnaylorls@gmail.com>,
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvoy9AJ4D2%2BpJE0ZRhPPCHh-Mm-sZAfookKtf_3V%2BGeP0g%40mail.gmail.com>
Precedence: bulk

On Mon, 16 Mar 2026 at 22:17, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Mon, 16 Mar 2026 at 20:01, Tender Wang <tndrwang@gmail.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.

Now pushed. Some concerns about the lack of exercise in the tests for
fastgetattr() for user tables. I ended up testing by injecting the
following into slot_deform_heap_tuple()

- attnum = slot->tts_nvalid;
+ attnum2 = attnum = slot->tts_nvalid;

[...]

+ for (attnum = attnum2; attnum < natts; attnum++)
+ {
+     Datum v = values[attnum];
+     bool  b = isnull[attnum];
+     values[attnum] = fastgetattr(tuple, attnum + 1, tupleDesc,
&isnull[attnum]);
+     Assert(v == values[attnum]);
+     Assert(b == isnull[attnum]);
+ }
+
  /* Fetch any missing attrs and raise an error if reqnatts is invalid */
  if (unlikely(attnum < reqnatts))

Still considering the best way to get a bit more coverage more permanently.

David