Skip site navigation (1) Skip section navigation (2)

Re: single bit integer (TINYINT) revisited for 8.5

From: Caleb Cushing <xenoterracide(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: single bit integer (TINYINT) revisited for 8.5
Date: 2009-07-01 17:03:19
Message-ID: 81bfc67a0907011003t12455490n35ddcf0e8fd57066@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-07-01 17:18:55
Subject: Re: 8.5 development schedule
Previous:From: Joshua TolleyDate: 2009-07-01 16:55:02
Subject: Re: 8.5 development schedule

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group