Re: Test timings are increasing too fast for cfbot

From: Andres Freund <andres(at)anarazel(dot)de>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: Test timings are increasing too fast for cfbot
Date: 2026-03-26 14:02:33
Message-ID: fmyp2nibfltgyonqdfjl73xfq7pikzwmc74vtkhrsgj6j4pmgn@7suvj7sylamj
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-03-26 11:09:36 +1300, David Rowley wrote:
> On Wed, 25 Mar 2026 at 16:15, Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2026-03-26 14:06:29 Re: Adding REPACK [concurrently]
Previous Message Robert Haas 2026-03-26 13:55:53 Re: pg_plan_advice