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
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? |