Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
