On Wed, 22 Mar 2023 at 10:42, Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 21.03.23 18:46, Andres Freund wrote:
> > 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.
>
> Btw., could attcacheoff be int16?
I had the same thought in '21, and in the patch linked upthread[0] I
added an extra comment on the field:
> + Note: Although the maximum offset encountered in stored tuples is
> + limited to the max BLCKSZ (2**15), FormData_pg_attribute is used for
> + all internal tuples as well, so attcacheoff may be larger for those
> + tuples, and it is therefore not safe to use int16.
So, we can't reduce its size while we use attcacheoff for
(de)serialization of tuples with up to MaxAttributeNumber (=INT16_MAX)
of attributes which each can be larger than one byte (such as in
tuplestore, tuplesort, spilling hash aggregates, ...)
Kind regards,
Matthias van de Meent
[0] https://www.postgresql.org/message-id/CAEze2Wh8-metSryZX_Ubj-uv6kb+2YnzHAejmEdubjhmGusBAg@mail.gmail.com
