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

Re: Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <momjian(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing
Date: 2008-04-25 21:37:07
Message-ID: 48124F03.7010306@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers

Tom Dunstan wrote:
> So two alternative proposals, both with a 2 byte "enum id" and a 2 byte "value":
>
> 1 - We space the values out as evenly as we can across the 65000ish
> range and allow people to delete, insert and append, but not reorder.
> If they do the above gratuitously we might have to do a rewrite, but
> they'll have to get fairly busy to do it. Rewrite would be required
> for reorderings.
>   

Or else we just error out in such cases. As Tom Lane suggests, rewriting 
has some nasty deadlock possibilities.

You always have the option of creating a new enum type and moving each 
affected column to that type.

> 2- We totally give up the idea of storing a value on disk that is
> directly comparable (other than equality), and simply number from zero
> up, using that number to index into an array (or use as syscache key
> or whatever) containing the real ordering information. We can then
> reorder or do any other operations to our heart's content.
>
> I'm actually favouring option 2 - I think it can be done in such a way
> as to not be much of an overhead compared to the status quo, and you
> know that if we don't implement proper reordering now, someone will
> ask for it, and we'll be having this discussion at a similar time
> after 8.4 goes out.
>
>
>   

Being able simply to order by the oid value is fast. That's one of the 
current benefits. So I think we'd need some benchmarking to show that 
this wouldn't slow things down.

cheers


andrew

In response to

Responses

pgsql-hackers by date

Next:From: Tom DunstanDate: 2008-04-25 22:01:37
Subject: Re: Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing
Previous:From: Bruce MomjianDate: 2008-04-25 21:35:53
Subject: Re: Proposed patch - psql wraps at window width

pgsql-committers by date

Next:From: Bruce MomjianDate: 2008-04-25 21:38:46
Subject: pgsql: Add URL for: * Allow adding/renaming/removing enumerated values
Previous:From: Tom LaneDate: 2008-04-25 21:32:59
Subject: Re: Re: [HACKERS] [COMMITTERS] pgsql: Fix TransactionIdIsCurrentTransactionId() to use binary search

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