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
