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 <t...@sss.pgh.pa.us> wrote: > "David G. Johnston" <david.g.johns...@gmail.com> writes: > > On Tue, Oct 22, 2024 at 4:40 PM Erik Sjoblom <sjoblo...@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 >
