Re: Save a few bytes in pg_attribute
От | Matthias van de Meent |
---|---|
Тема | Re: Save a few bytes in pg_attribute |
Дата | |
Msg-id | CAEze2Wjo38ZSMTWdsNxSBDe4U6_HommAtXLtHgTry0S1mEoU-w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Save a few bytes in pg_attribute (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Save a few bytes in pg_attribute
Re: Save a few bytes in pg_attribute |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: