Re: Save a few bytes in pg_attribute
От | Matthias van de Meent |
---|---|
Тема | Re: Save a few bytes in pg_attribute |
Дата | |
Msg-id | CAEze2WhKQA1JskkB3j526+ioEP6W_nefidAGJ2XWGbPX71f_Sw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Save a few bytes in pg_attribute (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: