public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Erik Sjoblom <[email protected]>
Cc: [email protected]
Subject: Re: Unexpected table size usage for small composite arrays
Date: Tue, 22 Oct 2024 18:34:52 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAAW=00XvzL9q6m2jgsd2YJJqzjjmBYyM3A1uaXuMMr19SpJ57A@mail.gmail.com>
References: <CAAW=00XvzL9q6m2jgsd2YJJqzjjmBYyM3A1uaXuMMr19SpJ57A@mail.gmail.com>

Erik Sjoblom <[email protected]> writes:
> I’m observing a storage behavior with arrays in a table that differs from
> my expectations, and I’d appreciate your insights. I was to store key value
> pairs in a very dense data model. I don't haver the requirement of search
> so that's why I was thinking an array of a composite type would work well.
> I can see that padding might be involved using the int4 and int8
> combination but there is more overhead. Anyone know where the following it
> coming from?

Composite values use the same 24-byte tuple headers as table rows do.
So you'd be looking at 40 bytes per array element in this example.
A large array of them would probably compress pretty well, but
it's never going to be cheap.

Can you store the int4's and int8's in two parallel arrays?

			regards, tom lane

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Unexpected table size usage for small composite arrays
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox