From: | Jeff Davis <jdavis-pgsql(at)empires(dot)org> |
---|---|
To: | jeff sacksteder <jsacksteder(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: unsigned types |
Date: | 2005-10-16 17:08:41 |
Message-ID: | 43528919.7010402@empires.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
jeff sacksteder wrote:
>
> The sign doesn't concern me. I am storing a value that is unsigned and 16
> bits wide natively. I'll have to just use an int4 and waste twice the space
> I actually need.
>
Are you sure you'd really save space with a 16 bit type? Often times
that savings gets lost in alignment.
As far as I know, the smallest type that PostgreSQL supports is 4 bytes.
On 64-bit architectures, it may be effectively 8 bytes (although I'm not
sure about that).
If you're concerned about space usage, you'll certainly be better off
using a packed type of some kind. For example, you could use an 8 byte
type, put 4 2-byte integers in it, and then have accessor functions that
return any of the given integers. Then make a view out of it, and
applications won't know the difference. Something like:
CREATE TABLE foo (
id serial primary key,
ints int8
);
CREATE VIEW foo_v AS SELECT id, getint(ints,0) AS int0, getint(ints,1)
AS int1, getint(ints,2) AS int2, getint(ints,3) AS int3 FROM foo;
of course you have to define the function getint() and setint() or
something like them, which should be easy to write in your favorite
language.
My advice would be to build the table the way you want it, and if it's
too bulky or slow, optimize it later. That's what is so great about
PostgreSQL, you can optimize, then just use a view and the application
will never know the difference.
I'll also mention that PostgreSQL has the built-in INET and CIDR types
which hold ip addresses/networks, but I assume those aren't what you're
looking for.
Hope this helps,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Janian | 2005-10-16 17:10:47 | Re: Long running update |
Previous Message | Tom Lane | 2005-10-16 17:07:29 | Re: Long running update |