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
