Re: BETWEEN Node & DROP COLUMN

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

In response to

Browse pgsql-hackers by date

  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