public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: David Rowley <[email protected]>
Cc: [email protected]
Cc: Dilip Kumar <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Noah Misch <[email protected]>
Subject: Re: Test timings are increasing too fast for cfbot
Date: Thu, 26 Mar 2026 10:02:33 -0400
Message-ID: <fmyp2nibfltgyonqdfjl73xfq7pikzwmc74vtkhrsgj6j4pmgn@7suvj7sylamj> (raw)
In-Reply-To: <CAApHDvo+aLV4XbiFzyuhX_aZa7uETar6Fb_OGya1WzHrvftEDw@mail.gmail.com>
References: <mtkrkkcn2tlhytumitpch5ubxiprv2jzvprf5r5m3mjeczvq4q@p6wkzbfxuyv2>
	<ogohyk54vjyejn3kdibrc73wcrdhwsq57fawxitycen6ntbzo3@gnnwuagu2qqj>
	<CAApHDvo+aLV4XbiFzyuhX_aZa7uETar6Fb_OGya1WzHrvftEDw@mail.gmail.com>

On 2026-03-26 11:09:36 +1300, David Rowley wrote:
> On Wed, 25 Mar 2026 at 16:15, Andres Freund <[email protected]> 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

view thread (9+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Test timings are increasing too fast for cfbot
  In-Reply-To: <fmyp2nibfltgyonqdfjl73xfq7pikzwmc74vtkhrsgj6j4pmgn@7suvj7sylamj>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox