From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Rod Taylor <rbt(at)zort(dot)ca> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BETWEEN Node & DROP COLUMN |
Date: | 2002-07-03 14:55:38 |
Message-ID: | 1025708138.23475.48.camel@taru.tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2002-07-03 at 14:32, Rod Taylor wrote:
> > > It should also be noted that an ALTER TABLE / SET TYPE implemented with
> > > the above idea with run into the 2x diskspace issue as well as take
> > > quite a while to process.
> >
> > I think that if the 'SET TYPE' operation is ever to be rollback-able, it
> > will need to use 2x diskspace. If it's overwritten in place, there's no
> > chance of fallback... I think that a DBA would choose to use the command
> > knowing full well what it requires? Better than not offering them the
> > choice at all!
>
> True, but if we did the multi-version thing in pg_attribute we may be
> able to coerce to the right type on the way out making it a high speed
> change.
If I understand you right, i.e. you want to do the conversion at each
select(), then the change is high speed but all subsequent queries using
it will pay a a speed penalty, not to mention added complexity of the
whole thing.
I don't think that making changes quick autweights added slowness and
complexity - changes are meant to be slow ;)
The real-life analogue to the proposed scenario would be adding one
extra wheel next to each existing one in a car in order to make it
possible to change tyres while driving - while certainly possible nobody
actually does it.
---------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-07-03 15:18:00 | Re: listen/notify argument (old topic revisited) |
Previous Message | Bruce Momjian | 2002-07-03 14:43:06 | Re: (A) native Windows port |