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

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.

cheers

andrew

In response to

• Re: [HACKERS] Enums patch v2 at 2006-12-19 14:58:48 from Alvaro Herrera

Responses

• Re: [HACKERS] Enums patch v2 at 2006-12-19 15:22:13 from Gregory Stark

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2006-12-19 15:19:34
	Subject: Re: [HACKERS] Enums patch v2
Previous:	From: Magnus Hagander	Date: 2006-12-19 15:07:55
	Subject: Re: pg_restore fails with a custom backup file

pgsql-patches by date

Next:	From: Tom Lane	Date: 2006-12-19 15:19:34
	Subject: Re: [HACKERS] Enums patch v2
Previous:	From: Alvaro Herrera	Date: 2006-12-19 14:58:48
	Subject: Re: [HACKERS] Enums patch v2