Feedback-ID: id4a34324:Fastmail
Date: Thu, 26 Mar 2026 10:02:33 -0400
From: Andres Freund <andres@anarazel.de>
To: David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-hackers@postgresql.org, Dilip Kumar <dilipbalaut@gmail.com>,
	Jelte Fennema-Nio <postgres@jeltef.nl>,
 Thomas Munro <thomas.munro@gmail.com>,
	Noah Misch <noah@leadboat.com>
Subject: Re: Test timings are increasing too fast for cfbot
Message-ID: <fmyp2nibfltgyonqdfjl73xfq7pikzwmc74vtkhrsgj6j4pmgn@7suvj7sylamj>
References: <mtkrkkcn2tlhytumitpch5ubxiprv2jzvprf5r5m3mjeczvq4q@p6wkzbfxuyv2>
 <ogohyk54vjyejn3kdibrc73wcrdhwsq57fawxitycen6ntbzo3@gnnwuagu2qqj>
 <CAApHDvo+aLV4XbiFzyuhX_aZa7uETar6Fb_OGya1WzHrvftEDw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAApHDvo+aLV4XbiFzyuhX_aZa7uETar6Fb_OGya1WzHrvftEDw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/fmyp2nibfltgyonqdfjl73xfq7pikzwmc74vtkhrsgj6j4pmgn%407suvj7sylamj>
Precedence: bulk

On 2026-03-26 11:09:36 +1300, David Rowley wrote:
> On Wed, 25 Mar 2026 at 16:15, Andres Freund <andres@anarazel.de> wrote:
> > Code wise, the most immediately noticeable things are
> 
> > 3) verify_compact_attribute(), pretty spread around
> 
> We do now have TupleDescFinalize(), where those could be checked just
> once rather than on each call to TupleDescCompactAttr(). That's not
> quite as watertight a guarantee as someone could change the
> FormData_pg_attribute after TupleDescFinalize(). Just doing it in
> TupleDescFinalize() would at least still catch the places where people
> forget to call populate_compact_attribute() before
> TupleDescFinalize().

Maybe verify_compact_attribute() could just do an assert comparison between
the underlying non-compact attribute and the compact one? Or even just an
assert checking if the compact attribute is initialized, with the full
checking happening in TupleDescFinalize(), as you suggest?


> I would have expected this to be a little less overhead now since
> d8a859d22 removed the calls to TupleDescCompactAttr() in the main
> deforming routine. Maybe I should just make that change in the other
> deformers...?

Might be worth it.


> Do you have an idea of which callers of verify_compact_attribute() are
> causing the most overhead?

I'm not sure how much to believe the profile when the costs are as distributed
as they are here. But according to the profile it's
- heap_form_tuple
- heap_form_minimal_tuple
- index_getattr
- nocachegetattr

Greetings,

Andres Freund