Re: single bit integer (TINYINT) revisited for 8.5

Caleb.

> I'd like to see this topic revisited since as far as I can see it
> hasn't been seriously discussed in years. I believe the main arguments
> against are why do we need more more numeric datatypes and increased
> maintenance. It would seem to me that a tinyint datatype maintenance
> wise would get all the same updates as the other int types, making it
> only a slight increase in maintenance. I think there was 1 more reason
> but I can't find the original thread now.

The main reason not to have one is that given byte-alignment, 95% of the
time using a tinyint would save no actual disk space or memory over just
using INT2 (or indeed INT4). I'll point out that the MySQLers are
enamored of the 3-byte integer, which even on MySQL saves zero space or
memory over using a 4-byte. Just because people like it doesn't mean it
works.

So the only real point in having an INT1 would be if you had a table
with a lot of them in a row; an unusual but not unheard-of design.
Still, that makes this feature less-than-critical for most users.

But ... the nice thing about PostgreSQL is that data types can be loaded
at runtime. Which means that you don't need INT1 in core for it to be
useful to you and others; just write the data type and put it on
pgFoundry. Then submit it for /contrib for 8.5, and we'll see how
popular the idea is.

Overall, I'm not keen on it. For the handful of times when
peformance-optimization-by-datatype makes sense, there's a large number
where it's develpers who have no idea what they're doing. We should be
moving in the direction of having the database engine take care of space
optimizations, not having the user do it.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com