Re: Single Byte values - Mailing list pgsql-general

From Jason Hihn
Subject Re: Single Byte values
Date
Msg-id NGBBLHANMLKMHPDGJGAPCEJHCGAA.jhihn@paytimepayroll.com
Whole thread Raw
In response to Re: Single Byte values  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: Single Byte values  (Manfred Koizar <mkoi-pg@aon.at>)
Re: Single Byte values  (Antti Haapala <antti.haapala@iki.fi>)
List pgsql-general
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Manfred Koizar
> Sent: Thursday, April 03, 2003 5:53 PM
> To: Jason Hihn
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Single Byte values
>
>
> On Thu, 03 Apr 2003 13:35:24 -0500, Jason Hihn
> <jhihn@paytimepayroll.com> wrote:
> >As someone pointed out, CHAR(1) costs 5 bytes.
>
> Jason, you already found out, that char(1) uses
>
> >4 bytes(stored string length) + 1 data in the case of char(1).
>
> All char(n) types are stored on 4 byte boundaries, so char(1) costs up
> to 8 bytes.

Is this true for memory AND disk, or just memory?

> >But in returning to my question, what should I be using for char(1) to
> >char(4) storage?
>
> Instead of char(1) you can use the Postgres specific type "char"
> (*with* the quotes) which only needs one byte.

So I assume use of this is 'safe'? Any degridation on performance?

It appears that this datatype is also array compatible, CREATE TABLE test3(a
"char"[4]); works!

I guess if space is so important, I could also just store
(char[0]<<8|char[1]) into a smallint...

> For char(n) a little toy has been posted to -hackers half a year ago
> (cf. discussion around
> http://archives.postgresql.org/pgsql-hackers/2002-10/msg00501.php).
> Feel free to play around with it.  Though I wouldn't take the trouble
> if only a few thousand rows are involved...
>
> Servus
>  Manfred
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>


pgsql-general by date:

Previous
From: Diogo de Oliveira Biazus
Date:
Subject: Re: feature request - adding columns with default value
Next
From: Stephan Szabo
Date:
Subject: Re: feature request - adding columns with default value