Re: Unexpected table size usage for small composite arrays - Mailing list pgsql-hackers

From Erik Sjoblom
Subject Re: Unexpected table size usage for small composite arrays
Date
Msg-id CAAW=00U8QDJyDYN-htRWvNYeG9R48Mm-G8Yd_f9qYjD8gghkVg@mail.gmail.com
Whole thread Raw
In response to Re: Unexpected table size usage for small composite arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Thank you both for explaining this!

Tom, your statement sounds like a good solution: " In principle we could squeeze those out and store them only once per array, but we don't."


On Tue, Oct 22, 2024 at 8:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Tue, Oct 22, 2024 at 4:40 PM Erik Sjoblom <sjoblom65@gmail.com> wrote:
>> I hear what you are saying Tom and what I have read says that it would
>> take 24 + 12 x N bytes for the array.

> Whatever you are reading, or your interpretation of it, is flawed.

I wonder whether Erik is confusing the array's overhead (which
by chance is also 24 bytes) with the composite-type overhead
appearing within each array entry.

In hopes of clarifying: in an array of composite, some though by no
means all of the composite-type overhead fields will be the same in
every entry.  In principle we could squeeze those out and store them
only once per array, but we don't.  It'd require essentially
duplicating a lot of the low-level array access code for this
different sort of array, and some operations would get slower.
Even simply fetching an element would get slower, since it'd have
to reconstitute a valid composite-type value from two pieces.

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Bill Smith
Date:
Subject: Re: msvc directory missing in PostgreSQL 17.0
Next
From: Alastair Turner
Date:
Subject: Re: Proposal for Integrating Data Masking and anonymization into PostgreSQL