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

Re: [HACKERS] Enums patch v2

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Tom Dunstan <pgsql(at)tomd(dot)cc>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Enums patch v2
Date: 2006-12-19 15:11:42
Message-ID: 4588012E.7020207@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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

Responses

pgsql-hackers by date

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

pgsql-patches by date

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

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