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