Re: Unexpected table size usage for small composite arrays

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Tue, Oct 22, 2024 at 4:40 PM Erik Sjoblom <sjoblom65(at)gmail(dot)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
>