On Tue, 21 Mar 2023 at 19:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andres Freund <andres@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
