Re: Postgres do not support tinyint?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Postgres do not support tinyint?
Date: 2025-01-08 06:53:34
Message-ID: 1590896.1736319214@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Tuesday, January 7, 2025, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> wrote:
>> 3. The "bit" type might serve your needs.

> You suggest a type with a minimum size of 6 bytes when the complaint is
> that the otherwise acceptable 2 byte data type is too large?

I think the point here is that there's zero value in trying to pack a
small integer value into 1 byte (let alone 4 bits) if it's all by
its lonesome in the row. Alignment padding will eat whatever gain
you thought you had. If you want a win, you need to store a lot of
such values in one field. Ron's suggesting that you pack them into
bit arrays and manually insert/extract individual values. That could
be worth doing if you were sufficiently desperate, but you'd have to
value compact storage over access simplicity quite a lot.

Perhaps a "char"[] array (note the quotes) would provide an
intermediate level of compactness versus pain.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message shammat 2025-01-08 11:15:19 Postgres 17 domains with NOT NULL and pg_get_constraintdef()
Previous Message Christophe Pettus 2025-01-08 06:49:08 Re: Postgres do not support tinyint?