Re: Enum proposal / design

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I think this is excessive concern for bit-shaving. Make the on-disk
> representation be 8 bytes instead of 4, then you can store the OID
> directly and have no need for the separate identifier concept. This
> in turn eliminates one index, one syscache, and one set of lookup/cache
> routines. And you can have as many values of an enum as you darn please.

Egads. bit-shaving is *important*. If it's 8 bytes you could just use a
char(4) and store 4 character text codes instead. The whole reason to want
this feature is precisely for bit-shaving.

I was originally going to reply with some thoughts about how we really ought
to fix things so that we don't need to store the type in every record of the
entire table. That would let you use 1 or 2 bytes for most applications.

Data density is the dominant factor controlling the overall speed of your
database. If you can shave 10% off the width of your records that's a 10%
speed gain in i/o and a 10% gain in headroom.

This is the same issue we have with char(n) and numeric(x,y) already. If we
found a general solution for getting the type name to the enum would it also
help getting the typmod to char(n) and numeric(x,y)? Would it let us store
those as fixed sized data types?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com