On Tue, 21 Mar 2023 at 19:55, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Andres Freund <and...@anarazel.de> writes: > > FWIW, I think we should consider getting rid of attcacheoff. I doubt it's > > worth its weight these days, because deforming via slots starts at the > > beginning anyway. The overhead of maintaining it is not insubstantial, and > > it's just architecturally ugly to to update tupledescs continually. > > I'd be for that if we can convince ourselves there's not a material > speed penalty. As you say, it's quite ugly.
Yes, attcacheoff is a tremendous performance boon in many cases. But all is not lost: When I was working on other improvements I experimented with storing the attributes used in (de)serializing tuples to disk in a separate structured array in the TupleDesc, a prototype patch of which I shared here [0]. I didn't see a speed difference back then so I didn't further venture into that path (as it adds complexity without performance benefits), but I think it can be relevant to this thread because with that patch we actually don't need the attcacheoff in the pg_atttribute struct: it only needs to be present in the derived "TupleAttrAlignData" structs which carry the length/alignment/storage/byval info. Kind regards, Matthias van de Meent [0] https://www.postgresql.org/message-id/CAEze2Wh8-metSryZX_Ubj-uv6kb%2B2YnzHAejmEdubjhmGusBAg%40mail.gmail.com
