Re: single bit integer (TINYINT) revisited for 8.5

On Wed, Jul 1, 2009 at 12:09 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> 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.

The primary type of field that I see it used as involves some sort of
statistics collection. like ratings, or maybe "strongly agree -
strongly disagree" (this could be in hundreds of colums), even
collecting gender's is appropriate if I recall.. as the iso for
genders is an integer with like 4 possible value's. At least this is
my thought, and a lot of these things end up in the same table.

It's not critical, but I'd suggest the benefits outweigh the costs.

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

I suppose I can see what I can do to this end (since it seems to be
the consensus) although it'll take me a while given I've no idea what
I'm doing... I can read C better than I write it, which doesn't say
much. On the other hand I'd think this would be on the list of
'easiest things to do' which means I should be able to get it done.

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

eh... not sure I agree on that 100%... but to some degree that's what
sql is for... at the same time that kinda sounds like sqlite's more
dynamic like typing. but it is another discussion

--
Caleb Cushing

http://xenoterracide.blogspot.com