Alvaro Herrera wrote:
Andrew Dunstan wrote:

As for efficiency, I agree with what Tom says about alignment and padding dissolving away any perceived advantage in most cases. If we ever get around to optimising record layout we could revisit it.

I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding.  So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid.  But
then, I'm not familiar with the patch at all so I'm not sure if it's

The trouble is that we have one output routine for all enum types. See previous discussions about disallowing extra params to output routines. So if all we have is a 2 byte offset into the list of values for the given type, we do not have enough info to allow the output routine to deduce which particular enum type it is dealing with. With the globally unique oid approach it doesn't even need to care - it just looks up the corresponding value. Note that this was a reduction from the previously suggested (by TGL) 8 bytes.

I'm not a big fan of ordering columns to optimise record layout, except in the most extreme cases (massive DW type apps). I think visible column order should be logical, not governed by physical considerations.



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to